Importing Turkish E-Invoices Into Logo, Mikro, Paraşüt and Netsis

Under Turkey's e-Fatura system, invoices travel between registered users as a standard file defined by the Revenue Administration (GİB). Companies use the system through GİB's own portal, through a licensed private integrator (özel entegratör), or by integrating their own systems with GİB directly (VUK General Communiqué No. 509, section V.1).

The invoice lands in the portal or the integrator's inbox, but the accounting software wants your codes: the supplier's account (cari), the stock or service code, the expense account, the cost centre. A supplier writes "Istanbul-Ankara transport" on a line; the invoice does not say which account or which branch that belongs to.

So many finance teams open each invoice on screen and retype it, line by line. The data is not missing. What is missing is the set of rules that ties it to your chart of accounts.

An e-Fatura is an invoice between two parties registered in the e-Fatura system. An e-Arşiv invoice is what a seller issues to buyers who are not registered. Registered taxpayers must send and receive their invoices to each other as e-Fatura, apart from the exceptions the communiqué lists (section IV.1.1). If your company is registered, invoices from registered suppliers arrive as e-Fatura.

The file format is UBL-TR, GİB's Turkish package built on the international UBL standard. Everything an automatic import needs sits in its own field:

• The issuer's tax number (VKN) or national ID number (TCKN), name and tax office
• Invoice number, date and unique identifier (ETTN)
• Each line's goods or service, quantity, price and amount
• VAT rate and amount, and any withholding amount and code
• The scenario: basic invoice or commercial invoice

The ETTN is unique to each invoice, which is how the import avoids posting the same invoice twice. A commercial invoice can be accepted or rejected by the buyer through the system within a set period; a basic invoice cannot. Invoices from foreign suppliers and from suppliers outside the system still arrive as PDFs or paper, and need their own path.

Every invoice takes the same path. The system logs each step, stops any invoice that breaks a rule and shows it to a person.

One screen shows where each invoice stopped, who approved it and which voucher number it posted under. When an auditor or your accountant asks, the answer is one search away.

Most of the work is writing rules, not software. We follow a month-end with your finance team, note how each invoice is coded today and turn that into explicit rules. Your finance team and your accountant (mali müşavir) sign them off; the system applies nothing else.

Rules are not buried in code; they sit in a table the finance team can read and update. When a new supplier, a new branch or a change to the chart of accounts comes along, the table is updated, and who changed what and when is recorded.

A good rule set is short and easy to audit. It is usually made of these kinds of rules:

VAT withholding (tevkifat) is not optional in Turkey: for transactions in scope the buyer must withhold, and for transactions out of scope the buyer may not. Which transactions are in scope, and at what rate, is set out in section I/C-2.1 of the VAT General Implementation Communiqué. As the buyer, you declare the withheld VAT yourself on VAT return No. 2.

The invoice carries the withholding amount and code. The import should compare them with your rule, not copy them blindly. An invoice whose code does not match your rule, or that arrives without withholding when you expect it, is held rather than quietly corrected. Writing to the supplier, and rejecting a commercial invoice if needed, is a person's decision.

The same check applies to VAT rates per line and to the exchange rate on foreign-currency invoices. Where a rule is unclear, your accountant decides; the system applies that decision the same way on every invoice.

Each product has its own official way to accept entries from outside. We use only that route and never write directly to the software's database tables, because that skips the software's own checks. Which route is available depends on version and licence; we settle it with you in the first week.

Some products also let you import an incoming invoice on their own screen. In Paraşüt, for example, lines can be matched while an invoice is imported from the Incoming e-Invoices screen, and for a handful of invoices that may be enough. Automatic import does the same matching on every invoice, by rules, without anyone opening a screen. The Mikro API goes further than listing incoming invoices: it also has endpoints to accept or reject them.

Rules carry the routine; everything that needs judgement stays with your team. Only these reach the approval screen: a new supplier, a line no rule covers, an amount that does not match the order, a withholding mismatch, a commercial invoice you may reject. It is the same team, spending its time on checks instead of retyping.

AI does two jobs. First, it reads invoices that have no UBL file: PDFs from foreign suppliers or scanned paper invoices. Second, for a line no rule covers, it looks at past entries and suggests an account. A person approves the suggestion, and a suggestion that keeps repeating becomes a rule the next month.

We built this for a Turkish fintech company: its incoming e-invoices now go into the accounting software automatically, by agreed rules, not line by line.

Before building the import we map how invoices move today. We sit with the finance team through a month-end and note every step from the moment an invoice lands in the integrator's inbox to the moment it becomes an entry: who opens it, what they check, which spreadsheet they take codes from, whose approval they ask for.

Then we start with the suppliers who send the most invoices, because most rules become clear there. In the first weeks the system only suggests: the team posts invoices as usual, compares them with the suggestion, and we write every difference back into the rules. Once the suggestions agree with the team's entries, the system is allowed to post; exceptions still go to a person.

Three things speed up the start: complete tax numbers on supplier accounts, a list of the account codes used for each expense type, and who holds which approval rights. If these already live in a spreadsheet, the first version of the rule table comes from it.

Your accounting software, your integrator and your chart of accounts stay as they are. The only change is whose hands put the invoice into the software. The code, the rules and the log are yours, and another team or firm can take them over.