# Invoice automation in Türkiye: where e-Fatura ends and AI begins.

> In this field note, veridive explains where e-Fatura ends and AI begins in invoice automation in Türkiye. Structured e-invoices arrive as data; the remaining work is foreign supplier PDFs, scans, delivery notes, credit notes and matching to orders and goods receipts. AI reads, matches and explains mismatches, while an accountant approves every entry.

Structured e-invoices already arrive as data. The hard part of invoice automation in Türkiye is everything else: foreign supplier PDFs, scans, delivery notes, credit notes and matching to orders. That is where AI helps, with an accountant approving every entry.

## Key takeaways

- Structured e-invoices already arrive as data, so the automation work lies in matching them and in everything that still arrives unstructured.
- AI reads foreign PDFs, scans, delivery notes and credit notes into the same fields your e-invoices already have.
- Mismatches with purchase orders and goods receipts are explained with evidence and never silently fixed.
- Connect to the ERP read-only first, then post drafts only after an accountant approves each entry.

In many [finance teams](https://veridive.com/insights/ai-for-finance-teams/) in Türkiye, accounts payable runs at two speeds. Domestic e-invoices arrive as data, find their orders and move toward posting with little typing. Next to them sits a folder of PDFs from foreign suppliers, a stack of delivery notes with handwritten corrections and a few credit notes that nobody has tied to their original invoices yet.

e-Fatura solved reading for a large part of the domestic flow. It did not solve matching, and it never touches the documents that still arrive as pictures of pages. That is where AI earns its place in invoice automation: reading the unstructured rest, matching everything to orders and receipts, and explaining every mismatch, with an accountant approving each entry.

## What does e-Fatura already solve?

e-Fatura is Türkiye’s electronic invoice system: invoices between businesses registered in it are exchanged as structured data files rather than on paper. For the receiving company, that changes one thing completely. The supplier’s tax number, the invoice number and date, each line with its quantity, unit price and VAT, and the totals are already fields. Nobody reads or retypes them, and there is no scanning error to catch.

What e-Fatura doesn’t tell you is whether the invoice is right for you. Was this ordered? Was it delivered, in this quantity? Is the price the one agreed? The line descriptions and units are the supplier’s, not yours: “koli” (box) on the invoice, “adet” (piece) in your item master. Coding to accounts, cost centers and projects is still your work.

> e-Fatura solves reading. It doesn’t solve matching.

Other e-documents exist too: e-Arşiv for invoices to recipients outside e-Fatura, and e-İrsaliye for delivery notes. Which suppliers must send which documents, and which your company must issue, are questions for your tax advisor. This note is general information, not legal or tax advice; it deals only with what arrives and what happens next.

## Which invoices and documents still arrive unstructured?

- **Foreign supplier invoices.** PDFs by email, in English, German or another language, each in its own layout, currency and date format.
- **Scanned documents.** Paper invoices and receipts that still reach the office, scanned at odd angles, often with a stamp across the text.
- **Paper delivery notes.** Printed, signed and stamped at the warehouse door, and often the only evidence of what actually arrived.
- **Credit notes.** Refunds, price corrections and returns that must be tied to the original invoice and the reason for the credit.
- **Handwritten corrections.** A quantity crossed out and rewritten on a delivery note, or a discount agreed on the phone and noted by hand.

## Where does AI help most: reading, matching or explaining?

All three, in different places.

**Reading** applies to the unstructured rest. The goal is to turn each document into the same fields an e-invoice already has, so everything downstream runs as one flow. Each extracted value links to the place on the page it came from, and checks run before anyone sees the draft: lines add up to the total, VAT is consistent, the supplier exists in your master data. Stamps, handwriting and Turkish characters need care; our note on [reading Turkish documents with AI](https://veridive.com/insights/turkish-ocr-documents/) covers them.

**Matching** applies to every invoice, electronic or not. Rules still do the exact checks, with tolerances set by finance. AI helps where rules struggle: a supplier description that doesn’t resemble your item text, one invoice covering three orders, a delivery split across two goods receipts, a box that holds twelve pieces.

**Explaining** makes the result usable. When an invoice doesn’t match, the draft says why in one sentence and shows the evidence: the invoice bills more than the goods receipt shows, or the unit price differs from the order line. A mismatch is never silently fixed. The system doesn’t adjust a quantity or a price to make the numbers agree; it proposes, and the accountant decides.

For e-invoices, most of the value is in matching and explaining.

## How do you handle foreign-currency and foreign-language invoices?

- **Currency as written.** The currency is extracted from the document, never assumed from the supplier’s country.
- **Exchange rates by policy.** Which rate and which date apply is a decision for your finance team and tax advisor. The system applies that rule from the source finance chose and shows the rate on the draft; a language model never supplies one.
- **Number and date formats.** “2.750,00” and “2,750.00” are the same amount, and “03/04” can mean March or April. The supplier’s country and past invoices settle most cases; ambiguous ones are flagged.
- **Languages.** Line descriptions keep their original text next to a translation, and item matching relies on how the same supplier’s lines were matched before, not on translation alone.
- **Identity.** Foreign suppliers are matched on their own registration or VAT numbers, name, address and bank details, never on name alone.

## Where must an accountant approve?

Every entry, before it posts. The system drafts; an accountant approves, edits or rejects each draft on a screen that shows the source document beside it. Some drafts deserve an extra look, and should say so:

- a new supplier, or a first invoice in a new currency;
- any change to bank details, which is never accepted from an invoice and is always verified by a person through a known contact;
- credit notes, which reduce or reverse earlier entries;
- mismatches beyond the agreed tolerance, and invoices with no purchase order;
- any field the system is unsure about.

The ERP connection follows the same logic. SAP, Logo, Netsis and Microsoft Dynamics are examples of systems a drafting step connects to, not partnerships, and the connection starts read-only: orders, receipts, supplier records and past entries. Writes come later, as approved drafts posted through the ERP’s own interfaces.

## How do you start with one supplier group?

Consider an illustrative distributor whose domestic e-invoices post cleanly, while a monthly batch of PDF invoices and credit notes from foreign suppliers, in euros and US dollars, still waits for someone to key it in.

1. **Choose the group.** The foreign suppliers: frequent enough to matter, bounded, and owned by one person in accounts payable.
2. **Use history as the answer key.** Past invoices and the entries accountants actually posted for them become the evaluation set, credit notes and corrected documents included.
3. **Connect read-only.** The system reads orders, goods receipts, supplier records and the exchange-rate rule, and writes nothing.
4. **Run in parallel.** For a few monthly batches, the system drafts while accountants key as usual, and the two are compared field by field.
5. **Approve, then write.** When drafts meet the threshold agreed at the start, accountants switch to review-and-approve, and approved entries post under the system’s own service account, with every step logged.

The [invoice-to-ERP drafting engagement](https://veridive.com/work/#invoice-erp) on our work page is an illustrative version of this path. Measure time from receipt to posting, fields corrected per invoice and mismatches caught before payment, against the baseline recorded before the pilot.

## The short version

Let e-Fatura do the reading it already does well, and point AI at the documents it doesn’t cover and the matching it never did. The [ERP and enterprise workflows](https://veridive.com/solutions/erp-enterprise-workflows/) page shows how a first project runs, and the drafting step itself is [custom AI software](https://veridive.com/services/custom-ai-software/) built around your approval rules.

## Frequently asked questions

### Does e-Fatura mean invoice processing is already automated?

Only partly. Structured e-invoices arrive as data, so nobody needs to read or retype them, but they still have to be matched to purchase orders and goods receipts, coded and approved. Invoices from foreign suppliers, scanned documents, delivery notes and credit notes often still arrive unstructured. Which invoices must be electronic is a question for your tax advisor.

### How can AI process PDF invoices from foreign suppliers?

AI can read a PDF invoice into the same fields an e-invoice already has, such as supplier, date, lines, currency and totals, and link each value to where it appears on the page. Automatic checks confirm that the lines add up and the supplier exists. The draft is then matched to the order and approved by an accountant before it posts.

### Can AI post invoices to the ERP automatically?

It shouldn’t, at least not at first. A safe design connects to the ERP read-only, drafts each entry and posts it only after an accountant approves, through the ERP’s own interfaces and under a dedicated service account. Systems such as SAP, Logo, Netsis and Microsoft Dynamics are examples of what such a drafting step connects to.

## Sources

1. About e-Fatura (in Turkish). Revenue Administration of Türkiye (GİB). https://ebelge.gib.gov.tr/efaturahakkinda.html
2. e-Fatura legislation and technical architecture (in Turkish). Revenue Administration of Türkiye (GİB). https://ebelge.gib.gov.tr/efaturamevzuat.html
3. About e-Arşiv (in Turkish). Revenue Administration of Türkiye (GİB). https://ebelge.gib.gov.tr/earsivhakkinda.html
4. About e-İrsaliye (in Turkish). Revenue Administration of Türkiye (GİB). https://ebelge.gib.gov.tr/eirsaliyehakkinda.html