In an e-invoice robot, reconciliation is the real work

When people hear “e-invoice robot” they usually picture “take the XML, write it to the ERP”. That is the easy half. The hard half is proving, every day, that two systems show the same truth: is every invoice on the e-invoice side also in the ERP, and does every ERP record rest on an actual document? This piece walks through a robot that connects an ERP to Türkiye’s national e-invoice infrastructure and produces a reconciliation report, and what 1 January 2027 means for flows like it.

Why now

General Communiqué No. 589 on the Tax Procedure Law, published in the Official Gazette on 31 December 2025, gave one more year to a specific group of taxpayers outside the e-Fatura and e-Arşiv systems: those on the simplified method or keeping business-account books. According to TÜRMOB’s circular, until 31 December 2026 they may still issue paper invoices up to 3,000 TL including taxes. From 1 January 2027 they must issue every invoice, whatever the amount, through the Revenue Administration’s e-Belge portal. For all other taxpayers the same rule has applied since 1 January 2026.

Seen from the buyer’s side, the meaning is simple. For a company that buys from tradespeople and small suppliers, the paper channel into accounts payable largely closes in 2027. Almost every incoming invoice will be either e-Fatura or e-Arşiv. I noted this briefly in the first radar. The question here is more practical: is the robot you already run ready for it?

How an incoming invoice reaches the ERP

The integration between the ERP and the e-invoice infrastructure, and the reconciliation report, are the backbone of the robot we delivered. The reading path for paper and PDF, the human review step and the adjustments for 2027 are the design I recommend for flows like this.

System

Intake

e-Fatura documents arrive through the integration channel; e-Arşiv and the remaining paper invoices arrive through other channels. All of them land in one intake queue, tagged with their source.

Rule

Identity and duplicate check

For an electronic document the ETTN, the supplier’s tax number and the invoice number form the key together. If the same document arrives twice it stops here; an invoice posted twice to the ERP is a lot of work to undo.

Model

Reading (exception path only)

A document without structured data, a paper invoice or one that only arrives as a PDF, is read with OCR. This is not the main path; its volume should shrink after 2027 and it should be measured separately.

Rule

ERP matching

Invoice lines are compared with the purchase order and goods receipt. If amount, quantity and tax are within a defined tolerance the posting is prepared; if not, the invoice is set aside with the reason.

Human

Exception review

An accounts payable specialist sees the unmatched invoice and records the decision with a reason. The robot does not try to guess that decision.

System

Posting and reconciliation report

The approved invoice is posted to the ERP. Each evening the documents visible on the e-invoice side are compared with the ERP records, and every document that stands alone on either side is listed in the report.

What we delivered

The e-invoice robot we built connects an ERP platform end to end with the national e-invoice infrastructure and produces a reconciliation report. We have built these integrations with Logo Tiger 3 and other ERP systems. I am not sharing the client’s name, volumes or internal detail. Some of the design notes below come from the backbone of that delivery and some from what I would add if I built a similar flow today; the labels in the walkthrough separate the two.

The Revenue Administration states the basic rule plainly: two taxpayers registered in e-Fatura must send and receive the invoices they issue to each other as e-Fatura. An invoice to a buyer who is not registered is issued on paper or as e-Arşiv. So a company’s incoming invoice flow is not one format; it is fed by at least two. The robot’s first job is to tag that difference at the source.

Why reconciliation is a separate job

Integration says “record the incoming document”. Reconciliation says “show that what you recorded is complete and unique”. The two can live in the same code, but they answer different questions and different people read them.

In a reconciliation report I want to see three lists:

Invoices visible on the e-invoice side with no counterpart in the ERP. These are usually pending, rejected, or skipped by the robot because of an error.
Invoices recorded in the ERP that cannot be tied to an electronic document. Manual postings and leftovers from the paper channel show up here.
Invoices on both sides whose amount or tax doesn’t agree.

If the first two lists are empty, the robot is doing its job. If they’re not, you want to know the next morning, not at month-end close. I think that is the real value of the report: it moves errors out of closing week and into daily work.

Where the rule, the model and the person sit

Rules carry most of this flow, and they should. An electronic invoice already has structured data. I see no reason to have a language model read the amount, the tax or the supplier. Duplicate checks, matching against order and goods receipt, and tolerance rules should be deterministic and explainable to an auditor in one sentence.

A model comes in for documents without structured data. Until 2027 that means paper invoices from small suppliers. I don’t expect it to disappear entirely afterwards. How an electronic document reaches you can depend on the supplier’s choices, and some invoices will still arrive only as a PDF. So I would keep the reading path, but build it as part of the exception path rather than the main flow.

The person is the only party who knows why a difference exists. Does a price gap come from an agreement, a partial delivery or a wrong order? I don’t want the robot to invent an answer; I want it to take the question to the right person with the right information.

Four things to adjust for 2027

Redo the volume forecast. If you run an OCR flow for paper invoices, 2027 volume will very likely fall. Don’t renew licences and capacity on this year’s figures; split your supplier list by who is on the simplified method or business-account books and forecast from there.
Make the channel tag mandatory. Keep the source channel on every invoice record. Without it you cannot measure whether the paper channel has actually closed.
Consider a separate intake path for e-Arşiv. The form in which an e-Arşiv invoice reaches you can vary by supplier. Before January, collect samples from your small suppliers and look at what actually arrives; don’t design on assumptions.
Break the reconciliation report down by channel. Seeing which channel the unmatched invoices came from often shows at a glance whether the problem sits in the robot or with the supplier.

When a robot is the wrong choice

To be honest, this job doesn’t always need a robot. If your ERP’s own e-invoice module or your private integrator’s standard connector covers the need, use that first. The Revenue Administration itself lists the portal, integration and private integration as separate ways to use e-Fatura. A robot earns its keep in the gap that connection leaves open: several ERPs, matching rules specific to your process, or a reconciliation task nobody owns.

Then there is maintenance. A robot that works through the screen needs checking with every ERP version change. Wherever possible I’d use a service or database interface instead of the screen, and keep the screen for steps that have no other way in.

Before you copy it

If you are thinking about a similar flow, ask one question on Monday: how many days does it take us to notice that an invoice visible on the e-invoice side is missing from the ERP? If the answer is “at month-end close”, your priority is reconciliation, not integration. And the 2027 calendar is not a good reason to postpone that work. It is a good date to start it.