Agentic ERP: what AI agents can and cannot do inside a finance system

An agentic ERP is a business system in which AI agents carry out multi-step work, such as matching payments, preparing accruals or chasing a missing receipt, rather than only answering questions. The agents act inside the system with a defined role, limits and an approval step, and every action lands in the same audit trail as human work. What they cannot do is take final responsibility for the books.

Most of the debate about agents in finance is about the agents: how smart they are, how many tasks they handle. The more useful question is about the system they work in. An agent is only as safe as the permissions, data and records around it, and in Germany the bookkeeping rules already describe most of what those have to look like.

---

What makes an ERP "agentic"?

Finance software has automated work for decades. Rules post recurring entries, scripts import bank statements, and robotic process automation copies data between screens. These tools follow instructions. When the input changes, they stop or, worse, keep going in the wrong direction.

An AI agent works towards a goal instead of a script. Given "match this month's incoming payments", it looks at each payment, finds candidate invoices, compares amounts, references and customer history, and decides which match is most likely. When it cannot decide, it asks. When a step fails, it tries another route.

The word "agentic" describes the system that hosts this kind of work. In an agentic ERP, agents are participants in the process: they pick up tasks, act on live data, hand over to people and leave a record. Our earlier article on AI agents for finance looks at the tasks themselves. Here the focus is on what the ERP has to provide.

What does an ERP need before agents can work in it?

A useful way to think about an agent is as a new team member on the first day. Nobody gives a new hire administrator rights and the payment release on day one. The same structure applies to agents, and it has to be built into the system, not added on top.

• One data model. An agent matching a payment needs the invoice, the order, the customer's history and the bank line in one place. If those live in four tools, the agent spends its effort on copying data and inherits every mismatch between them.
• A role. Each agent acts under a defined role with the permissions it needs and no more. An agent that prepares accruals has no reason to change supplier bank details.
• Limits. Value thresholds, entity boundaries and task scope define what an agent may do on its own and what needs a person.
• Approval. Above the limits, the agent prepares and a named person decides. The approval is part of the record, not an email.
• An unchangeable record. Every suggestion, approval, correction and posting is logged, including which agent or person did it and on what basis.

This is the difference between an AI-native system and AI added to an older one, a distinction covered in AI-native ERP vs AI added to an old ERP. In older systems, permissions were designed for people, and the AI often runs under a technical user with broad rights.

Where do German bookkeeping rules draw the line?

German law does not mention AI agents. It does not need to. The rules for bookkeeping apply to any process that creates bookings, whoever or whatever performs it.

The German Fiscal Code requires bookings to be recorded individually, completely, correctly, on time and in order (§ 146 Abs. 1 AO). Under § 146 Abs. 4 AO, a booking may not be changed in a way that makes its original content impossible to determine. For an agent, that means it can propose and prepare freely, but once something is posted, a correction is a new, visible entry, never a silent overwrite.

The GoBD (German digital bookkeeping rules, issued by the Federal Ministry of Finance and last amended in July 2025) add two expectations that matter for agents. A company needs an internal control system that makes the processing traceable. And it needs a procedural documentation (Verfahrensdokumentation) that describes how data flows through its systems, including the control mechanisms. An agent that books invoices is part of that process, so its role, limits and approval steps belong in the documentation, just as a human approval chain does.

Responsibility does not move either. Managing directors remain responsible for proper bookkeeping, and the tax advisor (Steuerberater) still signs off on what they file. An agent can reduce the work. It cannot take the accountability.

Which finance tasks can an agent take on, and which not?

A practical way to sort tasks is by two questions: can the output be checked against a source record, and can it be reversed before money or a filing leaves the company?

Agents can prepare almost anything. Reading invoices, suggesting accounts and cost centres, matching payments, drafting accruals and prepayment schedules, flagging anomalies, preparing the advance VAT return (UStVA) and the monthly report. All of these can be checked against documents and corrected before they matter.

Agents can handle clear cases within tight limits. A payment match that is exact in amount and reference, or a recurring invoice that matches last month's pattern, can be confirmed in bulk with a light review once the agent has a track record on your own data. How to judge that track record is the subject of how accurate AI is on accounting work.

People keep the decisions with consequences. Releasing payments, changing supplier bank details, posting material or judgemental journals, closing a period, filing tax returns and taking tax positions. The control logic for journals is in journal entry approval.

The boundary moves over time, as it does with a new colleague. But it moves because someone decided to move it, based on evidence, and that decision is documented.

What changes for the finance team?

When agents take on preparation, the work of the team shifts from doing to reviewing. Instead of typing in a hundred invoices, someone reviews the twenty the agent was unsure about. Instead of building the accrual list, the controller checks the suggested one and adds what the system could not know.

That shift needs different skills: reading confidence scores, spotting patterns in exceptions, deciding when a limit should change. It also changes what a good process looks like. A month-end where people approve prepared work in the system, with reasons attached, is faster and easier to audit than one where they redo the work in a spreadsheet.

The relationship with the tax advisor changes too. When the advisor receives bookings that were prepared by an agent and approved by a named person, with the source document and the reasoning attached, the review becomes a check of exceptions rather than a second round of data entry. That only works if the trail is complete. An agent whose suggestions cannot be traced back to a document, or whose approvals happen outside the system, creates more questions at year-end than it saves during the month. The quality of the record, not the speed of the agent, decides whether the time saved is real.

How does Agent F approach agents in the ERP?

Agent F is an AI-native ERP, and its agents work the way this article describes. Take the month's incoming payments. The agent matches each one to its open invoice, proposes the booking with a confidence score, and flags the payments it cannot decide, such as a partial payment without a reference. A named person approves the proposals and settles the flagged cases, and the immutable audit trail shows both the agent's proposal and the person's decision, on a ledger that follows HGB and GoBD.

For anyone evaluating agentic software, three questions help: under which role and permissions does the agent act, what happens to a posting it got wrong, and can you show the full trail of a single booking from source document to approval. If the answers are vague, the agent is working around the system rather than in it.

Learn how Agent F works, or see it on your own bookings at agent-f.ai/demo.