BAPI_INCOMINGINVOICE_CREATE is SAP's standard BAPI for posting an incoming AP invoice into FI/MM. Fin4Sight uses it as the only write path into SAP. Here's what that looks like in practice.

If you're evaluating an AP add-on for SAP, the question “how do you post invoices” matters more than the demo. The answer determines what your audit trail looks like, what your IT team has to maintain, and whether your add-on survives a SAP migration.

What the BAPI does

BAPI_INCOMINGINVOICE_CREATE takes an invoice payload — vendor, company code, line items, tax codes, currency, payment terms — and posts the invoice into SAP's standard tables. It returns either a successful posting (with the SAP belegnummer) or a structured set of error messages.

It's the same BAPI behind the SAP GUI transaction MIRO and SAP's standard APIs for invoice ingestion. Nothing custom, nothing proprietary, nothing your Basis team hasn't already audited.

How Fin4Sight uses it

After your configured approval workflow signs off on an invoice in the Fin4Sight web app, the platform calls BAPI_INCOMINGINVOICE_CREATE on SAP under a Basis-controlled SAP user. The payload is built from the OCR-extracted header and lines, validated against your tax-code rules and 3-way match logic, and idempotency-keyed against the Fin4Sight invoice ID.

The BAPI return is captured and stored back against the Fin4Sight invoice ID. Successful posts get the SAP belegnummer; failed posts get the structured error messages.

What can fail and how Fin4Sight handles it

Common BAPI failures and how the platform handles them:

• Vendor not found. The BAPI returns an error referencing the missing vendor. Fin4Sight surfaces it as an exception in the AP queue with the vendor reference for cleanup.
• Tax code mismatch. Fin4Sight's tax-code determination ran on intake; the BAPI rejection means SAP's tax configuration disagrees. The exception goes back into the queue with the tax-code reasoning visible.
• 3-way match failure. If the PO or GR don't agree, the platform's pre-posting validation usually catches this; if SAP catches it instead, the BAPI rejection routes back into the queue with the discrepancy detail.
• Authorization missing. The Basis-controlled SAP user lacks an authorization the posting needs. Fin4Sight surfaces the missing authorization object so your Basis team can adjust the role.
• Network or transient error. Idempotency keys on the Fin4Sight invoice ID let the platform retry safely without creating duplicate postings.

Every failure is logged with timestamp, BAPI return code, and the underlying message. The Fin4Sight audit log retains the failed attempts alongside the successful posting for 10 years.

The audit trail across two systems

Inside Fin4Sight: a complete state machine per invoice from intake to posting. User, timestamp, IP, and prior state on every transition. SHA-256 PDF hashes at intake and at posting. SOX-grade PDF report exportable on demand.

Inside SAP: a standard BAPI posting under the Basis-controlled SAP user, in the standard SAP audit log, with a standard belegnummer.

Reconciliation between the two systems is one field per invoice — the belegnummer stored on the Fin4Sight side. Two complete trails, one join key. No middleware to explain.

Why this matters for SOX, GoBD, and ISAE 3402

Auditors care about three things in priority order: a single source of truth, a continuous audit trail, and permissions enforcement. The BAPI-and-belegnummer model gives you all three.

The Fin4Sight side holds the invoice, OCR result, approval chain, and SHA-256 hashes — the source of truth for what the AP team did. The SAP side holds the belegnummer and the standard audit log — the source of truth for what posted to the books. Permissions are enforced on both sides: Fin4Sight's 7-role hierarchy on the workflow side, SAP's authorization model on the posting side.

It's not a single audit trail in the literal sense — it's two, with one join. But it's reconciled at the invoice level, every time, automatically. That's what passes audit.

When to ask harder questions

If an AP add-on tells you it posts to SAP but won't say which BAPI it uses, ask. The good answers reference standard SAP BAPIs. The bad answers reference custom posting transactions, service accounts with broad authorizations, ABAP enhancements, or middleware tools running between the cloud and SAP. Each one of those is a separate audit conversation you'll have to win.

In practice

Fin4Sight runs as a web app on Google Cloud Run. The intake, OCR, approvals, and audit log all live there. The posting goes to SAP via BAPI_INCOMINGINVOICE_CREATE. Nothing is installed inside SAP. Your Basis team controls the SAP user the BAPI runs under, and the standard SAP audit log captures every posting.

If you want to see this on your own SAP system, ask for a demo on a non-production system. Bring an invoice, watch it post, then SE16N the result.