Part 20: Would you let an agent post to your ERP?

Part 20 · One Agent, Five Platforms

Every build in this series so far stops before the ERP write. MuleSoft, Boomi and SAP all route post_invoice_adjustment through a person's approval, because Part 6 said so, and Part 19 made the process API check it every time.

So it's fair to ask: should it always stop there? Would you ever let an agent post to your ERP without a person approving that posting?

I don't think there's one right answer, so this part lays out the arguments, and I'm running a poll on LinkedIn alongside it. I'll share the results in a later part.

Where the line is today

It's worth being exact about what this series already allows:

• Within tolerance, nobody approves. An invoice that matches the PO and receipt within the agreed tolerance closes by rule (Part 6's first gate). But that's a rule posting, not an agent posting. No model is involved.
• Everything the agent proposes needs a person. At every stage of the rollout in Part 9, the write tools need an approval_id. The agent earns scope, not the right to skip approval.

So the real question isn't "should anything post automatically?" Plenty already does. It's "should a model's judgement ever reach the ERP without a person in between?"

The case for letting it post

• Approval fatigue is real. If approvers see hundreds of small, correct proposals a day, they start clicking approve without reading. Part 6 used exactly this argument to keep a person away from in-tolerance invoices. The same logic could apply to low-value, low-risk agent proposals.
• The evidence can justify it. By stage 3 of Part 9, there's a measured override rate per exception type. If approvers have accepted a type unchanged for months, the approval is adding delay, not control.
• Some fixes are easy to reverse. Releasing a hold once a missing goods receipt arrives is less risky than changing a price.
• Audit can replace pre-approval for some cases. A sample reviewed after posting, with fast reversal, is a normal control in finance. It doesn't have to be "approve everything first".

The case against

• Segregation of duties. In finance, the person who prepares a posting usually isn't the one who approves it. An agent that proposes and posts is both. That's a control question for auditors, not just a technical one.
• A model can be confidently wrong. A rule fails the same way every time. A model can fail in a new way after a prompt change, a model update or an unusual invoice. Part 9 already resets the evidence after every change for this reason.
• Errors scale. A person makes one mistake at a time. An agent with a bad prompt can make the same mistake on every invoice of a type before anyone notices.
• The cost of being wrong isn't symmetric. A delayed invoice costs a little time. A wrong payment costs money, supplier trust and, sometimes, a restatement.

A middle path: tolerance-based autonomy

If there's a version I'd consider, it looks like this, and every condition has to hold:

1. A low-risk type. Missing goods receipts and near-duplicates, the "quick approval" types from Part 2. Never tax, never closed POs, never price changes over tolerance.
2. A low amount. Below a threshold that finance sets and owns, like the tolerance itself.
3. Proven evidence. A low, stable override rate for that type over an agreed period, on the current model and prompt.
4. Post, then review. A sample of postings is reviewed after the fact, with a clear way to reverse.
5. An automatic way back. If the review finds errors, the type drops back to approval, as Part 9's "moving down" requires.

Even then, the process API from Part 19 still runs its checks. Instead of an approval_id from a person, it would check a policy approval: a recorded decision by finance that this type, below this amount, may post without per-item approval. The gate moves from each posting to the policy. It doesn't disappear.

Where I stand

For this series, nothing changes: every agent write needs a person's approval, on every platform, and the scorecard measures that. The middle path is something I'd only consider after a hands-on build has produced real override rates, not from documentation.

But I'm interested in where readers draw the line, because the answer probably depends more on the finance team than on the platform.

The poll

On LinkedIn, I'm asking one question with four answers:

• Never. The agent only proposes. A person makes every posting.
• With approval. The agent posts once a person approves, as in this series.
• Below tolerance. Low-risk, low-value types can post without per-item approval.
• Yes, with audit. The agent posts, and a sample is reviewed afterwards.

Would you let an agent post to your ERP?

---

This series describes a reference build on a fictional company. This part is a discussion, not a recommendation for any specific organisation; your auditors and finance team decide where your line is. Views are my own.