Why Fin4Sight runs next to SAP — not inside it

The two integration channels

Read channel: whitelisted Z-OData services. Your Basis team exposes the OData services they're comfortable with. Fin4Sight reads from those, and only those. Today the cockpit reads from FI, CO, MM, SD, PP, and HR through this channel — but you choose which OData services to publish.

Write channel: standard SAP BAPIs. The current AP Automation flow posts via BAPI_INCOMINGINVOICE_CREATE — the same BAPI your AP team would use through SAP GUI. No custom posting transactions. No service accounts inserting data into SAP through unsupported paths. SAP authentication, SAP authorization, SAP audit log on the posting side.

Two narrow doors. Both standard. Both controllable from your Basis side.

What stays clean inside SAP

Things Fin4Sight does not install in your SAP system:

• No transports
• No ABAP enhancements
• No SAP BTP middleware
• No service accounts created by Fin4Sight
• No custom posting transactions
• No agent or daemon process running on SAP application servers

If your auditor asks “what did Fin4Sight install in our SAP system?” the answer is “nothing.” The OData services pre-exist or are exposed by your Basis team using standard SAP tooling. The BAPI calls use standard authentication.

What you control on the Basis side

Your Basis team controls:

• Which Z-OData services Fin4Sight can read
• Which user account Fin4Sight authenticates as for OData reads
• Which user account Fin4Sight authenticates as for BAPI postings
• SAP authorization on those accounts (S_RFC, S_RFCACL, S_DEVELOP, S_TABU_DIS, etc.)
• Network whitelisting (Fin4Sight's outbound IPs to your SAP system)
• Audit logging on those accounts inside SAP

We don't ask for SAP_ALL. We ask for the minimum role to read the OData services you exposed and to call the BAPIs we need.

What it means for audit

Auditors see two systems with two complete trails. Inside Fin4Sight: every action with user, timestamp, IP, retained 10 years, exportable as a SOX-grade PDF. Inside SAP: BAPI postings under the SAP user we authenticated as, in the standard SAP audit log.

Reconciling the two is straightforward — every Fin4Sight-posted invoice has a BAPI return code stored against the Fin4Sight invoice ID, and the SAP belegnummer points back to the Fin4Sight ID via the standard reference fields.

The trade-offs, honest

A web-first add-on is not the right fit for every workflow. If you need real-time write-back to SAP from a custom workflow that doesn't exist as a BAPI, web-first costs you a custom posting layer. If your team prefers a SAP GUI experience, web-first costs you a context switch.

We think the trade-off is worth it for finance teams who care about audit, IT teams who care about ERP cleanliness, and CFOs who care about iteration speed. We won't pretend it's free.

Frequently asked questions

Do you ever install anything inside SAP?

No transports, no ABAP, no BTP middleware, no agents. The OData services we read are exposed by your Basis team using standard SAP tooling.

How do BAPIs handle errors and idempotency?

Each BAPI return code is stored against the Fin4Sight invoice ID. Failed postings are retried with the same idempotency key. Successful postings record the SAP belegnummer for reconciliation.

What's the latency of an OData read?

Depends on the SAP system, network, and OData service complexity. We schedule reads, cache where safe, and don't make synchronous OData calls in the user UI path.

Are there integrations with SAP-side automation tools (like Joule)?

Not currently. The architecture is intentionally narrow — Z-OData and BAPI only.