Accounts Payable: One Agent Must Never Propose, Approve, and Post the Same Transaction
By Equipo Quantum Developers
Summarize:
Operating thesis
The risk in an accounts-payable agent does not begin when it misreads an invoice. It begins when one identity can create a proposal, approve it, and cause it to reach the ledger or payment rail. The thesis is categorical: safe autonomy requires separate authorities for proposal, approval, and posting, with verifiable identity, evidence, and state at every transition.
The GAO Standards for Internal Control in the Federal Government describe segregation of duties, authorization, and documentation as control activities for responding to risk. That principle does not disappear when software performs a task. If several steps run under the same technical principal, using the same broad permission and no independent approval, three screens do not equal three controls.
Three authorities, not three messages from one agent
The minimum design distinguishes:
| Function | May do | Must not do |
|---|---|---|
| Proposal | extract data, test duplicates, match order and receipt, suggest coding | approve its proposal, change bank data, post |
| Approval | inspect evidence, approve, reject, return, or request exception | silently alter the document, execute payment |
| Posting | verify current approval and write to the ERP | create approval, change beneficiary, bypass a hold |
Each function needs a separate identity and least-privilege permission. Approval must come from a person or policy service independent of the proposing agent. Posting must reject any object lacking a valid approval, matching version, and completed prerequisite controls.
Separate models or prompts are not enough. Neither is one orchestrator invoking three tools with different names while retaining credentials capable of every action. The boundary belongs in the authorization layer of the system of record, not only in natural-language instructions.
A state machine the ERP can enforce
An invoice can move through explicit states:
received → validated → proposed → in review → approved → ready to post → posted → scheduled for payment.
Rejection, return, hold, and cancellation transitions must be equally visible. Each transition records actor, role, time, object version, applied policy, and evidence artifact. A material change—amount, vendor, bank account, currency, purchase order, or cost center—invalidates prior approval and returns the object to the required state.
Oracle’s documentation states that invoices and lines subject to approval must complete it before they become available for payment in its Invoice Approval Workflow guide. Implementation differs by ERP, but the agent design should use native restrictions. The agent should not merely “remember” to comply; the system should prevent bypass.
Treat a bank change as a separate process
An otherwise valid invoice can redirect money when beneficiary data changes. A vendor bank account is therefore not an editable field inside the same case. It is a protected object with its own requester, evidence, out-of-band verification, and approver.
Microsoft documents a workflow in which protected vendor bank-account changes are submitted for approval and proposed values are not used until approved in Dynamics 365 Finance. The pattern matters beyond the product: proposed change and active data are different states.
The invoice agent may detect a mismatch and place a hold. It must not create the new account, approve it, and continue. Even a valid invoice approval should be invalidated if the beneficiary changes before payment.
The transaction evidence packet
Every proposal should preserve:
- invoice, vendor, and legal-entity identifiers;
- an immutable hash or reference for the received document;
- purchase order, receipt, and applied tolerances;
- duplicate test and the searched population;
- proposed coding and supporting rule or evidence;
- master-data version and bank-data status;
- exceptions, conflict signals, and risk indicators;
- proposer, approver, and poster identity;
- approvals, comments, timestamps, and expiry;
- journal identifier and, later, payment outcome.
The packet need not expose sensitive data in a broad dashboard. It must allow an authorized reviewer to reconstruct the decision without depending on the agent’s memory.
Illustrative case: an invoice with changed beneficiary data
An invoice arrives with a matching order and receipt. The agent extracts the amount, proposes coding, and finds that the stated account differs from the master record. Although all other checks pass, it creates an exception and blocks progress toward payment approval. A master-data owner verifies the request through a previously registered channel; a separate role approves the change. Only then is a new vendor version created.
The earlier invoice proposal does not continue automatically. It returns to validation because material data changed. The approver reviews the new version, and the posting service confirms that the approval token corresponds exactly to it. This example does not prescribe the same headcount for every organization. It demonstrates that one identity cannot control every decision point.
Technical controls that make separation real
Use function-specific credentials, short-lived permissions, dual control for critical changes, and server-side ERP validation. A policy should compare proposer and approver identity and reject prohibited matches. Another should validate amount, entity, currency, beneficiary, and version before posting. Logs should resist alteration, and alerts should reach someone outside the execution chain.
Degraded operation matters. If approval or evidence storage is unavailable, the invoice waits. It does not pass through a “temporary” path with wider permissions. Break-glass accounts need authorization, time limits, and retrospective review.
In Quantum Automation Center, the timeline, artifacts, human approvals, and execution states can assemble the operating view. Effective separation still lives in identities and permissions of connected systems. Quantum should expose and orchestrate it, not imitate it.
Metrics that do not reward shortcuts
Cycle time and cost per invoice are useful but incomplete. Add proposal acceptance, outcome coverage, duplicates prevented, exceptions by cause, expired approvals, material changes after approval, segregation blocks, and discrepancy resolution time.
Report automation by state. “Automatically processed” must not mix extraction, proposal, approval, and posting. A high rate can be dangerous if achieved by reducing review or expanding permissions. ROI should use attributable improvement and the full cost of control, not the number of documents touched by the agent.
The strongest counterargument
In a small company, separating three functions can be slow and expensive when only a few people cover the cycle. The control may create a backlog and late payments while an owner already inspects bank movements personally.
That objection is real. The answer is not fictional separation. Use compensating controls: amount limits, external approval for exceptions, independent daily reconciliation, bank alerts, retrospective review, and an absolute prohibition on changing bank data inside the invoice workflow. When one person must accumulate functions, other evidence must detect error or abuse promptly.
When not to use this approach
Do not permit autonomous execution when effective separation is absent, vendor identity is unverified, or the ERP cannot enforce states and permissions. Keep the agent as extractor and proposer until those controls exist.
Do not automate exception payments to “recover” speed. The strongest initial use is often before the irreversible point: gather evidence, detect duplicates, propose coding, and route. Success is not removing people from the flow. It is reserving their judgment for an authorization that no single identity should grant itself.
Sources
Article topics
