e-Invoice (e-Fatura)
Generate GİB-compliant UBL-TR e-invoices straight from SAP billing and accept or reject incoming invoices inside SAP.
What problem does it solve?
Companies subject to e-invoicing must send every SD or FI invoice electronically in the UBL-TR format defined by the Turkish Revenue Administration (GİB), with the right scenario (basic / commercial) and against the taxpayer registry. Run outside SAP, this creates double entry, numbering gaps and documents reaching GİB late.
How does the solution work?
The solution generates UBL-TR at the moment of posting, checks the recipient's e-invoice status via the taxpayer query, selects the correct scenario and hands the document to the integrator. Incoming e-invoices land in SAP, where accept, reject and return decisions run through an approval flow and GİB responses are written back to the document. Which transmission method to GİB is used (a private integrator or the GİB portal) is decided during implementation.
What changes in practice?
An invoice is legally on its way the moment it leaves SAP; accounting and e-invoicing never diverge. Incoming invoice control runs from one screen and regulatory updates are applied at package level.
Benefits
- The e-invoice is generated the moment the invoice is posted in SAP; no double entry
- Incoming invoices are accepted, rejected or returned inside SAP
- The accounting entry and the document sent to GİB come from the same source
Where it sits in SAP
Integrated with SD billing and FI invoice postings; covers UBL-TR generation, the taxpayer query, scenario selection (basic / commercial) and writing GİB responses back to the SAP document. The transmission method to GİB (a private integrator or the GİB portal) is decided during implementation.
Who it is for: Finance Manager, Accounting and Sales Operations teams, IT
Frequently asked questions
How is transmission to GİB handled; can we keep our current integrator?
UBL-TR generation, the taxpayer query and incoming invoice management run on the SAP side; transmission to GİB and the return of responses go through a private integrator or the GİB portal. Which method and which integrator are used is decided at the start of implementation, taking your existing contracts and infrastructure into account. How the connection to your current integrator will be set up is clarified in the scoping discussion.
Who decides on accepting or rejecting incoming e-invoices, and is matching to purchase orders and goods receipts automatic?
When an incoming invoice lands in SAP it first appears as a pre-entry and enters the approval flow; who decides, by amount or vendor group, is defined during implementation. In the commercial scenario the accept or reject response is given from SAP and transmitted to GİB; in the basic scenario the return invoice mechanism is used instead of a response. Invoices carrying a purchase order reference are matched with the order and goods receipt, unmatched ones go to the user for review, and fully automatic posting is enabled gradually according to the company's matching rules.
How are cancellations and corrections handled once an e-invoice has been issued, and can the SAP document and GİB status diverge?
Once an e-invoice has reached GİB it cannot be corrected unilaterally; in the commercial scenario the buyer can respond with a rejection, otherwise the correction is made through a return invoice or a new invoice. The package runs these steps linked to the SAP document: when an SD cancellation invoice or FI reversal is created, the corresponding electronic document is generated and transmitted, and the GİB status is visible on both documents. The status in accounting and the status at GİB are therefore tracked through the same document chain and do not diverge.