In short

Mandatory e-invoicing gives accounts payable a second copy of every supplier invoice, held by the tax authority. In theory that makes reconciliation trivial. In practice the tax-portal copy and the ledger entry rarely line up row for row: the supplier names items its own way, uses different units, splits a delivery across invoices, or corrects the invoice two weeks later. Somebody has to pair the documents and explain every gap. That part is where AI earns its keep.

What AI should not do is decide. Claiming input VAT, rejecting an invoice, disputing a price and signing with a qualified certificate stay with a person.

This article walks through four regimes we work with: RO e-Factura in Romania, the allocation-number rule in Israel, e-Factura in Moldova and the ESF system in Kazakhstan. For each: what goes wrong, what an agent can take over, and what it should only prepare.

Why a formula does not solve reconciliation

If every line shared a reliable key, a standard report would match them. Real exports look like this:

  • Different item names. The supplier's invoice says "NYY-J 3x2.5 cable, 100 m drum"; the ledger says "Cable NYY 3*2.5".
  • Different units. Billed in metres, received in drums.
  • Split deliveries. One invoice covers three goods receipts, or the reverse.
  • Corrections. A corrected or credit invoice arrives after the original was booked.
  • Typos in references. Wrong PO number, wrong date, a counterparty with a similar name.
  • Duplicates. The same invoice arrives again as a PDF by email and gets keyed in by hand.

Exact matches on invoice number, tax ID, date and amount belong in deterministic code. The model works on what is left: pairing items by meaning, understanding that 100 metres is one drum, linking a correction to its original, and writing a plain-language explanation. It never does the arithmetic. Code compares every amount; the model proposes pairs and explains them.

Romania: RO e-Factura and the 60-day window

All B2B invoices in Romania have gone through ANAF's RO e-Factura system since 2024, and B2C invoices since 2025. From 1 January 2026 the issuer has five working days to upload an invoice, up from five calendar days (OUG 89/2025).

Two details matter for the buyer's AP team. Incoming invoices stay downloadable for 60 days after publication (ANAF procedure); miss the window and you are asking the supplier for the XML. And an invoice cannot be returned through the system: the buyer can send the issuer a message with objections, and the issuer corrects it under the Fiscal Code.

What an agent does well here:

  • pulls new XML files from SPV every day into your own archive, so nothing expires;
  • matches each invoice against the purchase order, goods receipt and bank statement before payment;
  • flags duplicates and suppliers missing from the vendor master;
  • drafts the objection message for each discrepancy, which an accountant reviews and sends.

Israel: allocation numbers and the input VAT deduction

Under the Israel Invoices reform, a buyer may deduct input VAT on an invoice above a threshold only if the invoice carries an allocation number (מספר הקצאה) issued by the Israel Tax Authority. The threshold has come down in steps: 25,000 NIS, then 20,000, then 10,000 from 1 January 2026, and 5,000 NIS before VAT from 1 June 2026 (Tax Authority VAT directive of 7 December 2025).

At 5,000 NIS, a large share of routine supplier invoices need a number. Suppliers' invoicing software, such as Priority, Morning (formerly Green Invoice) or iCount, usually requests it automatically, yet invoices still arrive without one, with a number belonging to another invoice, or with details that do not match. The Tax Authority runs a service to verify a supplier invoice by allocation number.

The agent's job is narrow and easy to measure:

  • pick out incoming invoices above the threshold;
  • check that each has an allocation number and that its details match the invoice;
  • before the VAT return, list the invoices whose deduction is at risk, with a draft request to each supplier in Hebrew or English.

Moldova: e-Factura for some, paper for the rest

Moldova's e-Factura system has existed for years, but it is not universal. Under Article 117 of the Fiscal Code it is mandatory for suppliers in public procurement and for taxpayers on the State Tax Service's list, which keeps growing by order. Some vendors announce a general B2B mandate; we found no legal act setting one by the end of October 2026.

So a Moldovan AP team usually runs two inbound streams: structured invoices from e-Factura and PDFs or paper from everyone else. The agent normalises both into one table, matches them against the ledger and shows which suppliers already issue through e-Factura. The PDF side uses the document extraction we describe in how an AI agent checks documents.

Kazakhstan: ESF and 1C

Kazakhstan's new Tax Code, in force since 2026, requires VAT invoices in electronic form, issued no earlier than the turnover date and no later than 15 calendar days after it (Articles 492 and 493 of the Tax Code); the standard VAT rate is now 16%. Incoming invoices sit in the state ESF system, and the accounting team matches them to goods receipts in 1C, the accounting software most local companies run.

1C's Kazakh accounting edition already compares turnover and VAT between its own invoice records and the ESF, so start with that report. The agent covers what the report can only flag as "does not match": ESF invoices with no receipt in 1C, receipts with no ESF, line items named differently, and corrected or revoked invoices that need linking to the originals. Goods tracked in the ESF "virtual warehouse" module add a third table to the same logic. For connecting an agent to 1C without changing its configuration, see AI for 1C.

How a reconciliation agent works

The pipeline is the same in all four countries; only the sources change.

  1. Collect. Exports from the tax system (SPV, Israeli allocation data, e-Factura, ESF) and from the ledger and bank. Files in a pilot, APIs later.
  2. Exact matching in code. Document number, tax ID, date, amount. This usually clears most of the volume.
  3. Fuzzy matching by the model. On the remainder, the model compares item names, units, split deliveries and corrections, and proposes pairs with a confidence level and a reason.
  4. Re-check in code. Every proposed pair is verified against amounts and VAT. A wrong guess from the model fails here.
  5. A summary for a person. Each discrepancy with its cause, links to both documents and a suggested action.
  6. Decision. The accountant approves, rejects or edits. The agent may create a draft entry and a draft supplier email; it posts and sends nothing without approval.

We measure quality on past periods: take a month the team already reconciled by hand and count the pairs the agent got right and missed. We do not recommend going live without that test; more on the method in why AI projects need evals.

Where a person stays in charge

The agent prepares decisions; it does not make them. Claiming or deferring input VAT, rejecting or correcting an invoice, signing with a qualified certificate and disputing price or quantity with a supplier all belong to the accountant or controller. Closed periods and filed returns are off limits.

One case gets special treatment: a long-standing supplier whose bank details suddenly change. That is the classic invoice-fraud pattern, so the agent flags it and never updates the vendor master itself.

Invoices from sole traders contain personal data, which affects what can go to an external model; see sending customer personal data to ChatGPT and Claude.

How to start this week

The first pass needs no development. Export a month of incoming invoices from the tax portal and the matching receipts from your ledger, strip columns you do not need, and give both files to ChatGPT or Claude on a business plan with a clear brief: find pairs, list unmatched documents on both sides, take every number from the files and cite the row. Check the first ten discrepancies by hand.

Once the review has to run weekly across several entities, it is time for an agent. That is what we build: AI agents for accounting workflows and the AI document assistant for invoices, acts and contracts. For more finance scenarios, read AI in finance.

FAQ

It can find pairs and discrepancies on its own once it has exports or API access to both the tax system and the ledger. Code still compares the amounts; the model handles item names, units and corrections and explains each gap. A person decides what to do with each discrepancy.

Not to a personal account. ChatGPT and Claude business plans do not train on your data by default. If invoices contain personal data of sole traders, mask it first or use a model running inside your own environment.

The XML is no longer downloadable from the system and you have to ask the supplier for it. An agent that archives new invoices every day removes that risk.

From 1 January 2026, invoices above 10,000 NIS before VAT; from 1 June 2026, above 5,000 NIS. Without a valid number, the buyer cannot deduct the input VAT on that invoice.

No. It removes the hours spent pairing rows and writing the same emails to suppliers. Judgement on VAT, disputes and fraud signals stays with the team, which now gets a short list of real exceptions instead of a 2,000-row spreadsheet.

Sources