The books close themselves

For forty years, the cost of running a finance function has been measured in keystrokes. Someone opens an invoice, reads it, types it into the ledger, matches it to a purchase order, chases the missing one and, eventually, approves a payment. Every automation wave since the scanner has attacked the same target: getting data off paper and into a system.

That target is about to disappear, and not because of any model. Governments are abolishing the unstructured invoice by law. When every invoice arrives as structured data, reading it is no longer work. What remains is the part that was always the real job: deciding who is allowed to act on it, how far, and on whose behalf.

The mandates are the forcing function

The European Union settled the direction in March 2025. The VAT in the Digital Age package was adopted on 11 March 2025, published in the Official Journal on 25 March and entered into force on 14 April 2025, according to the European Commission. From entry into force, member states no longer need permission from Brussels to make domestic e-invoicing mandatory. Digital reporting for cross-border business-to-business transactions follows from 1 July 2030, and the package is rolled out in stages until 1 January 2035.

Member states are not waiting for 2030:

• Germany has required every business to be able to receive structured e-invoices since 1 January 2025. Issuing becomes mandatory from 1 January 2027 for businesses with prior-year turnover above EUR 800,000, and for all domestic businesses from 1 January 2028 (EDICOM).
• Belgium made structured B2B e-invoicing between Belgian VAT-registered businesses mandatory from 1 January 2026 (KPMG Belgium).
• Poland's national e-invoicing system became mandatory in February 2026 for large taxpayers with turnover above PLN 200 million, with the rest following in later waves that year (OpenText).
• France has required every company, of every size, to be able to receive e-invoices since 1 September 2026, with large and mid-sized companies also issuing them from that date. Small and micro-enterprises must issue by 1 September 2027, and the same dates apply to e-reporting (impots.gouv.fr).

The pattern extends well beyond Europe. The UAE's Ministry of Finance issued Ministerial Decisions 243 and 244 on 29 September 2025: an invitation-only pilot from 1 July 2026, mandatory compliance from 1 January 2027 for businesses with revenue of AED 50 million or more, 1 July 2027 for the rest, and 1 October 2027 for government entities (EY). Malaysia phased in its own system from 2024, moving businesses with revenue between RM1 million and RM5 million to 1 January 2026 (Bernama via New Straits Times).

Read together, these are not tax reforms with a technology side effect. They are the end of the invoice as a document a person has to interpret.

When reading is free, acting is the job

Once an invoice is machine-readable by statute, extraction, coding and matching stop being the expensive part. Software, including agents, can do them reliably because the input is no longer ambiguous. That moves the bottleneck from data to decisions.

Look at what is left in a close. Approving a supplier's first invoice. Paying early to capture a discount. Writing off a small mismatch. Refunding a customer. Releasing a held order. Answering the supplier who asks where their money is. Every one of these is an act with consequences, and every one needs someone with the authority to take it.

The conventional view holds that finance automation is limited by accuracy: once the model is good enough, hand it the books. That gets the risk backwards. A model that reads an invoice perfectly can still pay the wrong party, because paying is a question of authority, not comprehension.

Fraud already targets authority, not data

The evidence is in the fraud statistics. The FBI's 2025 Internet Crime Report records USD 3.046 billion in reported business email compromise losses in 2025, second only to investment fraud, out of USD 20.877 billion in total reported losses. Business email compromise does not succeed by corrupting data. It succeeds by convincing someone with payment authority to use it: change the bank details, pay this invoice today, keep it quiet.

An agent that can pay inherits that attack surface. If it holds the same broad authority a finance clerk holds, the fraud does not need to fool a person any more. It needs to fool the agent once.

Permission, not ownership

The design answer is to separate what an agent can see from what it can do, and to make the second narrow, explicit and revocable.

An agent working in finance operations should act through the business's existing accounts with permission, not by taking ownership of them. The payment account, the ledger and the storefront stay the business's. The agent holds a grant to act inside them, and that grant has edges: which actions, which counterparties, what amounts, how often. Anything outside the edges stops and waits for a person.

This sounds like access control, and it is, but it changes how a finance team is organised. The scarce skill stops being data entry and becomes writing the limits: deciding that supplier invoices under a threshold that match a purchase order can be paid, that new bank details always need a human, that refunds above a level go to a named approver. A team that can write those limits precisely can delegate most of the close. A team that cannot will find that better models make no difference.

What this means for executives

The e-invoicing calendar gives you a deadline you cannot negotiate, so use it. Every finance system is being touched for compliance between now and 2028 in most of Europe, and by 2027 in the UAE. Treat that work as the moment to define delegated authority in writing: which decisions are mechanical, which need judgement, and who signs for the judgement.

Measure readiness by the quality of those limits, not by the share of invoices processed automatically. Ask your team three questions. Can we state, in one page, what an agent may pay without asking? Can we revoke that permission in minutes? Can we show an auditor every action taken under it?

What this means for CTOs

Structured invoices make the integration problem tractable, so the engineering effort moves to authorisation. Design for least privilege at the level of business actions, not API scopes: "pay matched supplier invoices under a limit" rather than "write access to payments". Keep the grant separate from the agent so it can be narrowed or withdrawn without redeploying anything. And make every run produce a record that a person can read later, because in finance the question after any incident is not what the model thought but who allowed it.

Where Praecise fits

Ipnops connects payments, accounting, commerce and mail, and acts across them with permission, never ownership. Every run stays within limits the owner sets and leaves a record. Businesses use it with Praecise Inbox, which gives people and agents mailboxes on a domain the business verified once with everything said kept in one searchable record, and with Skerry, which provides payment rails for agents including stablecoin settlement. Together they hand payments, books, orders and customer answers to agents across the accounts the business already uses.