e-Invoice integration in SAP: how to build an integrator-independent architecture

Most companies that set up e-invoicing together with SAP in Türkiye live through the same story: the first implementation is done with a plug-in supplied by the integrator; a few years later the integrator changes its pricing or its service quality drops, a switch is considered, and only then does it become clear that everything from invoice numbering to approval screens depends on that integrator's structure. The switch becomes a new project. This article describes an architecture in which the integrator is only a transmission channel and the process lives in SAP.

Four layers, one document

The foundation of an integrator-independent setup is separating the e-invoice process into four layers: document, conversion, transmission and response. The document layer is standard SAP; the SD invoice or FI document is created as always. The conversion layer produces the UBL-TR XML from that document, performs the taxpayer lookup, selects the scenario and runs the GİB schema checks. The transmission layer hands the finished XML to the integrator and receives the response coming back from GİB. The response layer writes that response to the SAP document and surfaces the status on the monitoring screen. The only place the integrator touches is the third layer; the first, second and fourth know nothing about it.

Why the conversion layer belongs in SAP

When UBL-TR generation happens outside, every field on the invoice — tax exemption codes, discount lines, exchange rates, order and delivery references — is carried out through a staging table and interpreted there. Every difference in interpretation comes back as a rejection at GİB or a dispute from the buyer. When conversion happens inside SAP, the XML is produced directly from the document, field mapping is defined in one place and schema changes are applied at one point. Validation also runs before the document is posted: a wrong tax code or missing tax number is reported to the user before the invoice is issued, not after it has gone to GİB and been rejected.

The incoming side: the approval flow lives on the document

Half of e-invoicing is incoming documents. In setups where accept and reject happen on the integrator portal, the accounting entry and the GİB status drift apart; an invoice accepted on the portal may never have entered SAP at all. In the right setup the incoming XML lands in SAP, is matched to the purchase order and goods receipt, routes to approval by amount and cost centre rules, the accept or reject decision is made on the document and transmitted to GİB from that decision. Years later, why a given invoice was rejected can still be read from the document history.

Parameterisation in multi-company landscapes

In holdings and groups the second benefit of integrator independence appears: the process is shared, the parameters are per company code. Each company's tax number, scenario preference, number range and integrator account are defined separately; even if one company wants to work with a different integrator, the process does not change. More than 200 company codes using the same e-invoice setup at Rönesans Holding is the proof that this approach scales.

Common mistakes

Leaving numbering to the integrator

The invoice number must be generated in SAP and go to GİB with that number. Where the integrator generates the number, a second mapping table appears between the SAP document and the legal document, and it is the first thing questioned in every dispute.

Not writing the response to the document

Leaving GİB and buyer responses only on the portal moves the "which invoices were accepted" question into a spreadsheet at close. The response must be written to the status field of the SAP document, and reports must come from there.

Skipping the test environment

Going live without running the GİB test environment, the integrator connection and the two-way flow for at least one full close cycle ends with bulk rejections at the end of the first month.

Conclusion

An integrator-independent architecture is not an anti-integrator architecture; it reduces the integrator's job to transmission and keeps the process inside SAP. The result is an e-invoice process that does not change when the provider does, regulatory updates managed in one place, and a closed gap between accounting and the legal document. The e-Invoice and e-Archive solutions in our catalogue come with this four-layer setup.