Türkiye E-Invoice Integration for ERP Systems
To operate in Türkiye, an ERP usually has to support e-Fatura and e-Arşiv — and e-İrsaliye in some sectors — through the Revenue Administration (GİB), normally via a private integrator. The ERP creates the document in UBL-TR format, the seller signs it with the financial seal (mali mühür), the integrator clears it with GİB, and the taxpayer stays responsible for retention throughout.
What must an ERP support to operate in Türkiye?
Türkiye runs electronic invoicing as a clearance system: a document is created by the seller, transmitted through an authorised channel, validated by the Revenue Administration and only then legally effective. For a business running its operations on an ERP, this has consequences at four points of the system: Tell us which ERP you run and which documents you issue, and we will quote the integration path to your integrator and the tax administration: request a quote.
- Document creation. The ERP — or a connected engine — must generate invoices in the required UBL-TR structure, with the codes, party identifiers and line-level data the schema demands, not a printed layout reshaped into XML.
- Digital signing. Documents are signed with the financial seal issued to the taxpayer; the signing step has to sit inside the flow, with key handling that matches the seal's custody arrangements.
- Two-way exchange. In the e-Fatura regime, the counterparty's registration status decides the document type, and incoming documents — invoices received, responses, cancellations where allowed — must land back in the ERP with their original identifiers, or accounting loses the link between the system and the official record.
- Archiving and retrieval. Issued and received documents must be retrievable for the statutory retention period; whether the integrator stores them, the ERP stores them, or both, is a decision to take before go-live rather than after an audit request.
One structural point that surprises teams new to clearance: the invoice is not finished when the ERP prints it. It is finished when the exchange completes and the responses come back, which means the ERP's notion of an invoice's state has to extend beyond "created" and "sent" to include accepted, rejected and corrected. Businesses that skip this end up reconciling two versions of the truth — their ledger and the official record — by hand at the end of the month, which is exactly the work electronic invoicing was supposed to remove.
Another point concerns timing. Documents in a clearance system are not asynchronous in the way an email attachment is: a rejection arrives while the team is still working, and the correction it demands usually touches master data rather than the document itself. Building the flow so that the person who can fix the cause is notified at the time, rather than discovering it in a monthly report, is the difference between a system that runs and a system that needs watching.
e-Fatura, e-Arşiv, e-İrsaliye explained
| Document | Used for | Typical trigger | Note |
|---|---|---|---|
| e-Fatura | B2B and business-to-government invoices between taxpayers registered for it | Both parties are registered for e-Fatura | A structured document exchanged between registered parties; counterparty status decides the route |
| e-Arşiv | Invoices where the buyer is not registered for e-Fatura — retail and B2C, and some B2B | Seller is within scope; buyer is outside the e-Fatura regime | Rendered as a PDF for the buyer, but generated and declared through the same chain |
| e-İrsaliye | Electronic delivery notes for the sectors and transactions designated by the rules | Shipment of goods within the covered flows | Couples to the invoice: the delivery note and the invoice reference each other |
| e-Defter | Books and records — ledger and day book, declared electronically | In-scope taxpayers, per the applicable rules | A separate obligation from e-invoicing, but usually planned in the same project |
Who falls under which obligation is defined by GİB rules and communiqués, which change; the thresholds and sector designations are set by the authorities and change with them. The correct statement for a buyer is a procedural one: check your registration status with your accountant or tax adviser against the current rules before designing the integration, not against an article — including this one.
Integration options
| Option | Fit | ERP effort | Watch-outs |
|---|---|---|---|
| GİB portal | Very small volumes, manual issuing | None in the ERP | Manual, slow, not a design target for a business with an ERP; keep it only as a fallback |
| Private integrator (özel entegratör) | The common route for most businesses | A connection to the integrator's API or format, plus mapping | Comparing integrators on support and API quality matters more than on the logo; ask who maintains the schema updates |
| Direct GİB access | Larger operations wanting full control | High: you take on the technical and operational responsibility of the channel | More complex to obtain and to run; described as rare in practice — treat it as an exception to justify, not a default |
The integrator model deserves one clarification, because it is often misunderstood: using a private integrator does not transfer the taxpayer's obligations. The integrator provides the technical channel, the transmission and the storage service; the legal responsibility for the documents — their correctness, their issuing and their retention under the Tax Procedure Law — stays with the taxpayer. When an integrator's sales page sounds like the compliance problem is being solved for you, read that sentence again.
In practice this split shows up in small, concrete ways. If a document is rejected because the customer's tax identifier was wrong in your master data, the integrator's system worked perfectly and the error is yours to fix. If an invoice is issued with the wrong tax code, no channel check will save you. The integrator is infrastructure; the data quality that flows through it is an internal discipline, and the ERP is where that discipline is either built in or left to habit. Buyers comparing integrators should therefore spend less time on the feature list and more on the questions that reveal who does what when something fails: who alerts whom, in what format, and how fast a corrected document can be retransmitted.
Implementation steps and testing
A workable sequence for an ERP-side integration:
- Fix the scope of obligations. Which documents apply to the business — e-Fatura, e-Arşiv, e-İrsaliye, e-Defter — confirmed against the current rules with the company's accountant.
- Choose the channel. Most businesses select a private integrator; the selection questions — API quality, sandbox availability, support language and hours, schema-update handling, references — are worth a shortlist exercise of their own.
- Map the master data. Customers and their tax identifiers, items, units, currencies and tax codes must map to the schema's expectations; mismatches here are the largest single source of later errors.
- Design the document flow. Who creates what, when the seal is applied, what happens on failure, how outgoing and incoming documents are matched to ERP records, and how corrections are issued.
- Use the test environment. Both sides offer a test environment; run every document type, every error path and every correction scenario through it before go-live, with the same mapping used in production.
- Handle errors as a process. Rejections arrive after transmission; someone must see them, understand the cause and correct the underlying data — an alert inbox without an owner is how a business ends up issuing documents late.
- Plan archiving and access. Where documents are stored, who can retrieve them, and how an auditor's request is answered within the retention period.
Foreign-parent and non-resident points to ask an adviser
For a company with a foreign parent, or one entering Türkiye without a full local finance team, several questions belong with a tax adviser rather than with the IT project — the answers determine the design, so ask them before the integration starts, not after:
- Registration path. How does the company become subject to the obligations, who signs the applications, and which representative is recognised — questions of tax registration, not of software.
- Seal arrangements. How the financial seal is obtained for the company and how its custody is organised when signers are outside Türkiye.
- Representatives and signatures. Who is authorised to sign which documents, and what the ERP must record about the signer for the audit trail.
- The foreign-subsidiary position. Whether any additional requirements apply to companies with non-resident ownership, and how intra-group invoicing is treated.
It also pays to decide who owns the relationship with the adviser. In companies where finance and IT both assume the other has asked the question, these points reach the integration late — usually in the weeks before go-live, when the document flow is already fixed. A named owner on each side, and one joint meeting before step 3 of the implementation, prevents most of that.
Common issues
The failures that show up most often in this kind of project, and what each usually points to:
- Rejections at validation. Almost always a mapping problem: a tax code, an identifier format or a line-level field that does not match the schema's expectation. Fix the master data, not the retry logic.
- Duplicate numbering. Number sequences generated by more than one system, or re-generated after a failure; numbering must have exactly one owner and a documented recovery rule.
- Counterparty status mistakes. Issuing the wrong document type because the customer's registration status was cached or assumed; look the status up per the integrator's rules rather than per memory.
- Incoming documents lost. Documents received but never posted back to the ERP, so accounts payable works from a separate screen; the exchange direction is part of the integration, not an optional extra.
- Schema updates missed. The structure changes over time; whoever is responsible must know when it changed and what the change did to the mapping.
- Test skipped under deadline. Every issue above is cheaper in the test environment; go-live pressure is where they become incidents.
Frequently Asked Questions
What is the difference between e-Fatura and e-Arşiv?
e-Fatura covers invoices exchanged between taxpayers registered for the regime, as structured documents between registered parties; e-Arşiv covers invoices where the buyer is outside that regime — retail and B2C, and some B2B — which the buyer typically receives as a PDF generated through the same official chain. Which one applies to a given invoice follows from the counterparty's registration status, which is why the integration checks it rather than assuming.
Do I need a private integrator?
For most businesses, yes — that is the common route, and the direct channel is described as complex and rare. A private integrator provides the technical channel to GİB and the storage service; your obligations as a taxpayer remain yours. Choosing one is a procurement exercise: API quality, sandbox, support and schema-update handling decide the daily experience more than the brand does.
What is the financial seal (mali mühür)?
It is the taxpayer's digital signing credential used to sign electronic documents before they are transmitted; custody and who may use it are practical questions to settle inside the company. For teams with signers outside Türkiye, the arrangement of who holds and applies the seal is one of the first points to put in front of a tax adviser.
Can any ERP issue Turkish e-invoices?
No. The ERP must generate the required UBL-TR structure with correct master data, or be connected to an engine or integrator that does; a standard invoice layout is not enough. Most businesses therefore connect rather than rebuild — the question to ask a vendor is which integrators their connector supports, what it maps, and where its documentation is.
How do I test before go-live?
Through the test environments provided on both the integrator and the official side, using the same master data mapping as production: every document type, every rejection path, every correction and every incoming document posted back to the ERP. Treat the test as a rehearsal of the error process as well — someone must receive, diagnose and fix a rejection, not just see a green tick.
Who stores the invoices?
The taxpayer stays responsible for retention under the Tax Procedure Law; the integrator typically provides technical storage, and many businesses also keep documents in their ERP for daily use. What matters is deciding the arrangement before go-live, knowing who can produce which document within the retention period, and testing that retrieval before an auditor asks for it.
Sources and standards
- GİB — Gelir İdaresi Başkanlığı — the Revenue Administration publishes the rules, communiqués and technical documentation for e-Fatura, e-Arşiv, e-İrsaliye and e-Defter; the current versions there override everything summarized on this page.
- Registration status, thresholds, sector designations and deadlines are set by the authorities and change; confirm with your accountant or tax adviser against the current rules. Nothing on this page is tax advice, and no integrator relationship, partnership or certification is claimed for WorldwideTradeX.
Related pages
Software development · Odoo ERP for trading companies · Custom vs packaged ERP · IT audit and consulting · Request a quote