How does ml-connector prevent duplicate GL postings when Stripe charges are retried?

ml-connector stores an external document reference (REF_DOC_NO) in every BAPI_ACC_DOCUMENT_POST call using the Stripe charge ID. If the same Stripe charge is received again due to a webhook retry or network timeout, SAP ECC detects the duplicate reference and rejects the duplicate posting without creating a second GL entry. This is checked at BAPI posting time.

What does the on-premises agent do and why is it required?

SAP ECC is on-premises and has no cloud API gateway. RFC/BAPI calls cannot originate from the internet; they must come from inside the customer's network. ml-connector runs a lightweight agent on the customer's network that makes RFC calls to SAP ECC using SAP .NET Connector or Java Connector, while the cloud portion of ml-connector receives Stripe webhooks and orchestrates the sync. The agent is stateless and does not store credentials locally.

Which Stripe events are posted into SAP ECC?

Successful charge.succeeded events and invoice.finalized events are posted as GL transactions. Refunds and disputes are posted as reversals or adjustment entries in the same GL account and cost center. Payment failures and canceled subscriptions do not generate GL postings unless explicitly configured for accrual accounting.

SAP ECCStripe

SAP ECC and Stripe integration

SAP ECC runs finance and procurement for large enterprises. Stripe handles payments and invoicing for web and mobile businesses. Connecting the two keeps your general ledger in agreement with your payment and subscription data. Stripe charges and invoices post into SAP ECC's general ledger on the same schedule they occur, mapped to GL accounts and cost centers tied to your customer master data. ml-connector manages the complexity of SAP ECC's RFC layer and ensures every payment transaction is posted exactly once.

How SAP ECC works

SAP ECC exposes vendors, customers, GL accounts, cost centers, materials, purchase orders, and accounting documents through RFC/BAPI function modules, OData v2 REST via SAP Gateway, or SOAP web services on an on-premises host. Authentication uses HTTP Basic Auth for OData and SOAP, or RFC Basic Auth via SAP .NET Connector or Java Connector for direct BAPI calls. SAP ECC has no native webhook system, so transactions are read by polling RFC_READ_TABLE or via outbound IDoc push configured by the customer's SAP Basis team. All reads and writes require an on-premises agent running on the customer's network.

How Stripe works

Stripe is a cloud payments platform that exposes customers, invoices, charges, subscriptions, and payment intents through REST API at https://api.stripe.com/v1. Every request authenticates with an API secret key sent via HTTP Basic Auth. Stripe pushes payment events via HTTPS webhooks with HMAC-SHA256 signatures to a registered endpoint, with at-least-once delivery and 3-day retry windows. Prices and products are immutable after creation. Stripe has no vendor, PO, or GL account concepts; it is a transactional ledger for payments and subscriptions only.

What moves between them

Payment and invoice data flow from Stripe into SAP ECC. When a Stripe charge succeeds or an invoice is issued, ml-connector reads the transaction details from Stripe via REST and posts the financial entry into SAP ECC's general ledger using BAPI_ACC_DOCUMENT_POST, mapped to the GL account and cost center assigned to that customer. Customer master records in Stripe can be synced back into SAP ECC's customer table for AR reconciliation. Refunds and adjustments in Stripe are also posted into SAP ECC as reversals or adjustment entries.

How ml-connector handles it

ml-connector runs an on-premises agent on the customer's network that makes RFC calls to SAP ECC via SAP .NET Connector or Java Connector. For every Stripe webhook event received, the agent reads the full transaction details from Stripe's REST API, then prepares a GL posting and calls BAPI_ACC_DOCUMENT_POST with an external document reference in the REF_DOC_NO field to prevent duplicate postings on retry. Stripe webhooks carry an HMAC-SHA256 signature that ml-connector verifies before processing. Customer master synchronization uses RFC_READ_TABLE to pull the SAP ECC customer list and maps it to Stripe's customer objects by an external ID stored in a custom field. Charges are posted daily or on demand depending on your sync schedule. ml-connector caches customer mappings to avoid N+1 queries, validates GL accounts and cost centers before posting, and tracks SAP ECC BAPI return codes to detect lock conditions or posting errors.

A real-world example

A B2B SaaS company built on Stripe for subscription payments and invoicing integrates with SAP ECC at their corporate parent, which uses ECC for consolidated GL, AR, and intercompany settlement. Before the integration, the finance team exported Stripe transaction reports weekly, manually matched them to customer master records in SAP ECC, and re-entered the GL postings by hand to reconcile AR every month. With SAP ECC and Stripe connected, Stripe charges and invoices post automatically into SAP ECC's GL every day, tied to the matching customer cost center, and AR reconciliation is complete as transactions settle. The manual re-keying step is gone and payment data integrity is audited.

What you can do

Post Stripe charges and invoices into SAP ECC's general ledger with no manual re-entry, tied to GL accounts and cost centers.
Sync customer master records between Stripe and SAP ECC to keep AR and customer data in agreement.
Authenticate Stripe via API secret key and SAP ECC via RFC/BAPI using an on-premises agent, with full HMAC signature verification on Stripe webhooks.
Detect and prevent duplicate GL postings using external document references and idempotency tracking on every Stripe charge.
Track every transaction with a full audit trail, including BAPI return codes, customer mappings, and retry history.

Questions

How does ml-connector prevent duplicate GL postings when Stripe charges are retried?: ml-connector stores an external document reference (REF_DOC_NO) in every BAPI_ACC_DOCUMENT_POST call using the Stripe charge ID. If the same Stripe charge is received again due to a webhook retry or network timeout, SAP ECC detects the duplicate reference and rejects the duplicate posting without creating a second GL entry. This is checked at BAPI posting time.
What does the on-premises agent do and why is it required?: SAP ECC is on-premises and has no cloud API gateway. RFC/BAPI calls cannot originate from the internet; they must come from inside the customer's network. ml-connector runs a lightweight agent on the customer's network that makes RFC calls to SAP ECC using SAP .NET Connector or Java Connector, while the cloud portion of ml-connector receives Stripe webhooks and orchestrates the sync. The agent is stateless and does not store credentials locally.
Which Stripe events are posted into SAP ECC?: Successful charge.succeeded events and invoice.finalized events are posted as GL transactions. Refunds and disputes are posted as reversals or adjustment entries in the same GL account and cost center. Payment failures and canceled subscriptions do not generate GL postings unless explicitly configured for accrual accounting.

Connect SAP ECC and Stripe

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started