Who approves what when an AI agent works in your ERP?

An AI agent in your ERP needs an approval matrix: admins configure its rules, finance approves its actions, and thresholds by amount, entity and customer decide who signs off. With Transformance, 100% of postings are validated and none posts without human sign-off.
Frosted-glass cubes routing through colored approval tiers, visualizing ERP approval matrices by amount and role

Key Takeaways

  • An approval matrix names the threshold and the approving role for every agent action, built from your delegation of authority.
  • Give each action a rule by amount, entity and customer, and let the strictest decide who signs and how many people do.
  • A lack of internal controls contributed to 33% of occupational fraud cases and an override of existing controls to 19% (ACFE, 2026).
  • Segregation of duties covers the agent too: admins write the rules, finance approves, and with Transformance nothing posts without human sign-off.

In This Article

Who approves what when an AI agent works in your ERP?

Admins configure the agent’s rules and thresholds, finance staff approve its actions, and thresholds by amount, entity and customer decide which person signs off and how many people do.

Example approval matrix for an AI agent in accounts receivable

Agent actionWhat it changesExample rule (amount / entity / customer)Approver (example)Who sets the rule
Propose a match, dispute case or reminder draftNothing yetEvery proposal lands in the work queue with its evidenceAR analyst reviewsAdmin
Send a standard reminderCustomer contactYour policy choice: approve the reminder template once, or each reminder; key accounts and customers with an open dispute excludedAR leadAdmin
Agree a payment planCustomer agreementUp to 60 days and USD 50,000: AR lead; above: controllerAR lead or controllerAdmin
Clear a payment against open itemsLedger (clearing posting)Every clearing signed off; above USD 250,000 or intercompany: second approverAR lead; controller as secondAdmin
Post a short-pay differenceLedger (difference or residual item)Within the customer group’s tolerance (e.g. USD 25 or 0.5%): analyst; above: dispute case firstAR analyst or AR leadAdmin
Write off a residualLedger and P&LPer entity: up to USD 1,000 AR lead, up to USD 25,000 controller, above CFOAR lead, controller or CFOAdmin, limits from your DoA
Issue a credit memo or reverse a postingLedger and customer balanceNever the person who proposed it; closed period or above USD 10,000: controllerControllerAdmin
Change a rule or thresholdConfigurationWritten by an admin, approved by the controller, loggedControllerAdmin (author)

Example policy: you configure every value. Amounts are illustrative; take yours from your delegation of authority (DoA).

An approval matrix is a table that names, for every agent action, the threshold that applies and the role that signs off, so nobody decides case by case who may approve. Your delegation of authority already sets write-off and credit memo limits for people; the agent needs the same table, extended to every action it can take.

Gartner predicts that at least 15% of day-to-day work decisions will be made autonomously through agentic AI by 2028, up from 0% in 2024, and that over 40% of agentic AI projects will be canceled by the end of 2027, inadequate risk controls among the reasons (Gartner, 2025).

Controls fail in familiar ways. In the ACFE’s study of 2,402 occupational fraud cases from 143 countries and territories, a lack of internal controls contributed to 33% of cases, an override of existing controls to 19% and a lack of management review to 18%, together 70% (ACFE, Occupational Fraud 2026). The study is not about AI, but an approval matrix addresses all three gaps for an agent.

‍

‍

Transformance supplies the mechanics: multi-level approvals with thresholds by amount, entity and customer, roles that separate the admins who configure rules from the finance users who approve, and no posting without human sign-off. Your finance team supplies the policy.

‍

‍

How do you sort agent actions by what they change?

Sort every agent action by what it changes: nothing yet (a proposal), a customer relationship (a message or agreement), the ledger (a posting) or the rules themselves (configuration).

  • Proposals change nothing. A proposed match, dispute case or reminder draft is reviewed in the work queue with its evidence.
  • Customer contact changes the relationship, not the ledger. Reminders, calls and payment plans reach the customer. Your policy decides which customers always get a person, such as key accounts and customers in an open dispute.
  • Ledger writes need sign-off. Clearing postings, differences and residual items, write-offs, credit memos, journal entries and reversals change the balance sheet, the P&L or the customer’s statement. With Transformance, every one waits for a person.
  • Configuration changes the next thousand decisions. A write-off limit raised from USD 1,000 to USD 5,000 moves every later write-off. Tolerances and routing thresholds are configuration, and configuration in a control should be “versioned, segregated between author and approver, promoted through environments, and logged” (Uniqus, 2026).

Transformance names its approval levels read, recommend, execute and post, with a human in the loop for ERP postings.

How do thresholds by amount, entity and customer work together?

Give each agent action a rule by amount, entity and customer, and let the strictest win: a large amount, new entity or sensitive customer brings in a senior approver.

  • Amount. Tiers per action, taken from the limits your people already have.
  • Entity. Per company code, subsidiary or legal entity. Reasons for a stricter rule: the first 90 days after go-live, a local statutory signatory, a different local currency, a period in close. See AR across legal entities.
  • Customer. Key accounts, open disputes, intercompany partners and related parties get a named approver or a lower limit. This rule needs the dispute and promise history on the same record as the open items, as in a Customer 360 view.

SAP works the same way. During clearing, SAP S/4HANA checks the employee’s tolerance group and the customer’s: “The payment difference must be within both tolerances to be handled automatically” (SAP Learning, S/4HANA course). Strictest wins applies that logic to approvers.

Illustrative example (figures are fictional). The agent proposes to write off a USD 12,000 residual for a key account, in an entity that went live six weeks ago.

  • The amount tier says controller (above USD 1,000, up to USD 25,000).
  • The entity rule says controller for any write-off in the first 90 days; six weeks is day 42.
  • The customer rule says the key account owner co-signs.
  • Result: two signatures, controller and key account owner.

Two gaps show up in practice: without a customer rule, a customer in an open dispute gets a reminder that reads as automatic; without an amount rule, a USD 400,000 clearing passes at the analyst tier. Some teams add a daily total per approver, so 200 write-offs of USD 900 cannot add up to USD 180,000 under one AR lead’s signature in a day. Short-pay rules in detail: partial payments and deductions.

How do you keep segregation of duties between rule authors and approvers?

Segregation of duties for an AI agent means admins configure rules and thresholds, finance users approve actions, and nobody approves an action under a rule they wrote.

Transformance separates the two roles. People sign in through SSO/SAML, and role-based access control (RBAC) sets what each role can see and approve. Name four roles before go-live:

  • Rule author: the finance systems admin who writes rules, tolerances and thresholds.
  • Rule approver: the controller who approves each rule or threshold change.
  • Action approvers per tier: AR analyst, AR lead, controller, CFO.
  • Log reviewer: internal audit, sampling sign-offs.

“If one system identity can propose, justify, and post a credit adjustment, it combines duties that the control design should keep separate,” writes Uniqus (2026). With Transformance, Vero proposes and a person approves. How the agent’s own ERP identity and access are scoped: how AI agents access ERP data safely.

Add two same-person checks: whoever resolved an exception does not sign off its posting, and whoever proposed a credit memo does not approve it. A full segregation of duties matrix lives in your internal control framework; these roles are what an AI agent adds.

How do the ERP’s own approval controls fit in?

Keep the ERP’s own approval functions switched on as an outer fence, and set the posting user’s limits so the ERP rejects anything above your approval matrix’s top tier.

  • SAP S/4HANA and ECC. Employee tolerance groups set the maximum document amount a user may post, the maximum customer or vendor line item, the maximum cash discount and the maximum payment difference; “every user can be explicitly assigned to a tolerance group” (SAP Learning), and SAP’s documentation allows them per company code (SAP Help, 4.6C release). So the user an external system posts under can carry your top tier as its cap. Entries are “always in the local currency” (SAP Learning): a limit of 25 is USD 25 in a US-dollar company code and JPY 25 in a yen one, so convert per company code. For G/L entries, SAP delivers “a predefined, one-step approval workflow” (SAP Learning). More in the SAP S/4HANA integration.
  • Dynamics 365 Finance. Approval is set per journal name: no approval, manual approval by a user group, or workflow approval. With no approval, “the same user can create and post the journal without intermediate review” (Microsoft Learn, 2026). See the Dynamics 365 Finance & Operations integration.
  • NetSuite. With Require Approvals on Journal Entries enabled, “a user with the Journal Approval permission (Edit level or higher) must approve each journal entry before it’s posted”; by default only Administrators hold it, and reversals are approved with their original entry (Oracle NetSuite Help). See the NetSuite integration.
  • Oracle Fusion Cloud ERP. The ledger and the journal source must both be enabled, and approval covers the whole journal batch. For subledger sources, Oracle advises against GL journal approval: “approvals for subledger transactions should be done in the subledgers themselves” (Oracle, Fusion Financials 26A). Transformance supports Oracle: the Oracle integration.

GL journal approval workflows are built for manual journals. Clearing postings and payment differences from an external AR system are receivables postings in the sub-ledger, so their approval has to happen before the write, in the AR layer, with the ERP’s user limits as the backstop.

The ERP still validates every write: a closed posting period, a blocked item or an exceeded tolerance rejects the posting, approved or not, so a rejected posting needs an owner in your matrix too. Posting mechanics: how external systems post payments and clear open items.

What does an approver see before signing off?

An approver should see the proposed entry, its evidence, the validation result and the threshold that applies, so the sign-off is a decision rather than a click.

Vero, the Transformance agent, investigates an exception from Customer 360, fetches information from internal and external sources to find more matches, then proposes with the evidence: for a short pay, the remittance line, earlier deductions and the open dispute. A person approves, changes or rejects. ClearMatch validates 100% of postings, and nothing posts without human sign-off.

The audit log records the timestamp, what the system did, what the user did, who approved, the input and the confidence; more in what an AI agent’s audit trail records.

Two habits keep sign-off real:

  • A rejection needs a reason code. The reasons feed your monthly threshold review. Uniqus (2026) names the risk: “If the approval is only a quick check, the agent has effectively made the judgment.”
  • A confidence score is evidence, never a limit. In your matrix, the amount, entity and customer rules decide who signs, whatever the score.

Vendor questions: the enterprise AI vendor checklist.

How do you set up and adjust approval thresholds safely?

Start with your existing limits on one entity, review rejections and corrections monthly, and raise a threshold only as a logged change approved by someone other than its author.

Set up an approval matrix for an AI agent in seven steps

‍

‍

  1. List every action the agent can take and group it by what it changes: nothing yet, customer contact, the ledger or configuration.
  2. Copy the amounts from your existing delegation of authority for write-offs, credit memos and payment plans; do not invent new limits for the agent.
  3. Set the amount tiers per action and the approver role for each tier, keeping a person on every ledger posting.
  4. Add entity rules: stricter limits for newly live entities, closed periods and entities that need a local signatory.
  5. Add customer rules: key accounts, customers with an open dispute, intercompany partners and related parties get a named approver.
  6. Separate the roles: admins write rules and thresholds, finance approves actions, and nobody approves under a rule they wrote.
  7. Mirror the top tier in the ERP: set the posting user’s limits so the ERP rejects anything above the matrix, then review rejections monthly before changing a threshold.

A proof of value runs in 4-5 weeks on one entity. The ERP connection typically takes 2-3 days, and your IT team may be involved; the full rollout takes up to 4-8 weeks. Name the posting approver and the exception owner before the proof of value starts (implementation timeline).

Raise a limit on your own evidence: rejections per action and tier, corrections, reversals and time to sign-off. If an AR lead approves 400 short-pay postings a month and rejects none for three months, the review may have become a quick check; look at a sample before raising the limit.

Tighten the same way for a new entity, a reorganised team or a period close.

Who Transformance is for

  • ERPs: finance teams on SAP S/4HANA, SAP ECC, NetSuite, Microsoft Dynamics 365 Finance & Operations and Business Central, or Odoo (all in production with customers), and on Oracle or Infor (supported), who want multi-level approvals with thresholds by amount, entity and customer.
  • Size: mid-market to large enterprise, 250 to 2,000+ employees, including groups with several entities and shared service centres.
  • Payment volume: from under 1,000 to over 100,000 payments a month.
  • Industries: manufacturing, consumer goods and food and beverage, logistics, e-commerce, agriculture, energy and professional services.
  • Scope: cash application alone, or the full order-to-cash (cash application, deductions, AR collections, cash forecasting).

Conclusion: write the policy before the agent writes to the ledger

An AI agent in the ERP is as controlled as its approval matrix: actions sorted by impact, three threshold axes, separate rule authors and approvers, and ERP limits as backstop.

Bring your delegation of authority to the first workshop: Transformance configures thresholds by amount, entity and customer on it.

Key terms

  • Agentic AI: AI that carries out multi-step work toward a goal, within limits people set.
  • AI governance: the policies, roles and controls that decide what an AI system may do and who answers for it.
  • Audit trail: the record of who did what, when and on which input.
  • Write-off: removing an uncollectible balance from receivables, usually under an approval limit.
  • Credit memo: a document that reduces what a customer owes.
  • Escalation matrix: a table of who takes over an item at which trigger; the approval matrix is its sign-off counterpart.

Related guides

‍

‍

Frequently Asked Questions

Can an AI agent post to the ERP without approval?

With Transformance it cannot: nothing posts to the ERP without human sign-off, and ClearMatch validates 100% of postings first. In your approval matrix, thresholds by amount, entity and customer decide who signs and how many people do, never whether a posting is signed.

Can a confidence score replace an approval threshold?

No. A confidence score tells the approver how strong the evidence is; your amount, entity and customer rules decide who signs. Transformance records the confidence in the audit log, and a person signs off every posting whatever the score.

Which ERPs does the Transformance approval model work with?

Transformance runs in production with customers on SAP S/4HANA, SAP ECC, NetSuite, Microsoft Dynamics 365 Finance & Operations and Business Central, and Odoo, and supports Oracle and Infor. Multi-level approvals with thresholds by amount, entity and customer are part of the platform.

Can approval thresholds differ per legal entity or company code?

Yes: thresholds can be set by entity as well as by amount and customer, and multiple SAP company codes, NetSuite subsidiaries or Dynamics 365 legal entities run in one Transformance environment, for groups from 250 to 2,000+ employees.

Who configures the approval rules?

Admins configure rules and thresholds, and finance users approve the actions; Transformance keeps the two roles separate. People sign in through SSO/SAML, and RBAC sets what each role can see and approve.

How long does it take to set up approvals with Transformance?

The ERP connection typically takes 2-3 days, and your IT team may be involved; a proof of value runs in 4-5 weeks on one entity, and the full rollout takes up to 4-8 weeks.

What does Transformance cost?

Cost depends on scope and the number of entities, from cash application alone to the full order-to-cash. Book a Call for a figure for your setup.

SAP, SAP S/4HANA, Microsoft, Dynamics 365, Business Central, Oracle, NetSuite, Odoo and Infor are trademarks of their respective owners (SAP SE, Microsoft Corporation, Oracle Corporation, Odoo S.A., Infor). Transformance is not affiliated with or endorsed by them.

Continue reading