Guide
E-invoicing integration in Türkiye: how it works
Updated:
The technical part is usually a few days of work. What delays these projects is almost always preparation and sign-off — so this guide covers that too.
Türkiye operates a mandatory electronic invoicing regime. Integration means your sales system — a commerce site, an ERP or custom software — issues the invoice document and gets it to the buyer without manual intervention. This guide covers the flow, the options, and where things get stuck in practice.
Scope note: what follows is the technical side. Which document type applies to your transactions, and how tax is calculated, belong to your accountant. Be cautious of proposals that blur those two.
First decision: provider or direct?
There are two routes, and for most businesses the first is correct.
| Route | Suits | Upside | Downside |
|---|---|---|---|
| Through an authorised provider | The large majority of businesses | Fast to set up; the provider tracks regulatory and schema changes | Monthly or quota-based fee |
| Direct integration | Very high volume, special requirements | No intermediary cost | Certificates, schema and regulatory tracking all fall on you; permanent maintenance load |
The honest advice: unless your volume genuinely exceeds the intermediary cost, use a provider. Direct integration is not a job that finishes on the day it is built — regulation and document schemas change over time, and following every change is an ongoing burden.
The technical flow: order → invoice → buyer
A working setup typically runs like this:
Where these projects actually get stuck
Delays in integration projects usually come from these, not from code:
Put these in the contract
Ask for these four even if you work with someone else:
Frequently asked
How long does e-invoicing integration take?
Through a provider, a standard one-way flow (order → invoice) is typically running within 1–3 weeks. What stretches the timeline is preparation, not code: getting the test account opened, having tax and exemption rules confirmed in writing, and making sure buyer detail fields are actually collected on your site. With those three ready it moves quickly; without them the development side simply waits.
Which provider should we choose?
This is a commercial decision more than a technical one: pricing model, quota structure, support quality and what your accountant is used to all matter. On the technical side we care about three things: a documented API, a working test environment and meaningful error messages. With those, the integration is straightforward. We suggest choosing the provider with your accountant and leaving the technical assessment to us.
Will it work with our existing accounting system?
If there is a connection point, yes: an API, database access or scheduled file transfer. Most accounting and ERP systems common in Türkiye offer some integration route. Closed systems can be handled with file-based workarounds — these are fragile and need maintenance whenever the software is updated, and we say so up front.
What happens with refunds?
A refund is a separate document flow and must be in scope from the start. The setup works like this: when a refund is approved, the corresponding document type is issued, linked to the order record in your system, and the status written back. Leave this out of scope and the first refund pushes the work back to manual — and in practice it never becomes automated afterwards, because “we already do it by hand” turns into habit.
Would we notice if the integration broke?
If it is built correctly, immediately. In the flows we build, failed documents wait in a queue, are retried automatically, and raise an alert once they pass a threshold. The dangerous property of a badly built integration is silence: the problem tends to surface at month-end reconciliation, which is exactly when it is most expensive to repair.
Let us map your invoicing flow
Tell us which systems you run and how invoices are issued today. We will say clearly which steps can be automated.