Map the invoice and payment as separate records
A fictional distributor, Alder Supply, receives invoice AS-240 for $2,400 from an established supplier. The invoice refers to a purchase order, but the receiving team has recorded only part of the delivery. The AP team wants an agent to assemble the evidence and prepare a draft, while a person decides how to handle the difference.
That is a useful starting scope because the output is concrete: a draft linked to the source invoice and the relevant purchasing records. The agent can explain why it needs review. It should not mark the invoice payable merely because the total was extracted correctly or the supplier appears in the master record.
The swimlane below shows a recommended division of work. Supplier, agent, AP reviewer and bank each produce a different record. It also makes the boundary between approving an invoice and releasing a payment visible to the person operating the system.
An invoice draft does not release money
- Supplier
Sends AS-240 for $2,400 with an order reference.
- AP agent
Prepares a draft and links the partial receipt evidence.
- AP reviewer
Resolves the receipt exception and approves the appropriate invoice treatment.
- Payment approver
Reviews the separate instruction and verified beneficiary.
- Bank connection
Returns the instruction reference and subsequent status for reconciliation.
Understand the documented ERP boundary
Microsoft's Payables Agent prepares purchase invoice drafts and finalizes them as unposted purchase invoices in Business Central. Draft review is distinct from the Business Central approval workflow, and the agent does not post the invoice. That boundary is central to evaluating the product. [1]
For an AP pilot, ask what the ERP receives after the agent finishes. Is it a draft, an unposted invoice or a posted obligation? Then identify the next approval and the permission required for the next system action. Do the same for payment preparation and release. Avoid treating all these records as a single “processed” status.
A review interface also needs to show exceptions in the right context. Microsoft's supervision documentation describes reviewing agent work, providing instructions and stopping tasks. These are useful supervision features to examine in a demonstration; they do not establish that an AP agent supplies your bank's payment authorization process. [2]
If your accounting system differs from the one in the documentation, verify the integration separately. A familiar invoice screen or a list of ERP logos does not tell you which fields can be written, which permissions apply or how the system handles an interrupted operation.
Put controls beside the relevant risk
For Alder's invoice, the receiving discrepancy belongs beside the order match. A supplier-bank-detail change belongs beside beneficiary verification. A repeated invoice reference belongs beside duplicate detection. This organization helps the reviewer understand why a proposal is stopped and which owner can resolve it.
Use the controls matrix as a planning worksheet. Each check needs an input and a defined response. “Check duplicates” is incomplete without deciding which supplier identifiers, invoice references and prior records the check uses. “Ask for approval” is incomplete without naming the approver and the fields that the approval covers.
A free-text comment on an invoice may explain a decision, but it should not silently expand the agent's permissions. If a user tells the agent to ignore a mismatch, preserve that instruction and route the decision through the appropriate review process. The task owner needs to know whether the instruction came from someone authorized to make that decision.
Controls at the point of decision
Scroll the table to compare all columns.
| Risk | Evidence to inspect | Owner | Expected response |
|---|---|---|---|
| Duplicate invoice | Supplier identifier, reference and existing records | AP reviewer | Stop a second proposal until identity is resolved |
| Partial receipt | Order quantity and recorded receipt | Receiving and AP owners | Keep the mismatch visible before approval |
| Changed beneficiary | Verified master record and change request | Supplier-master owner | Verify independently of the invoice document |
| Changed amount after review | Approved version and revised proposal | Invoice approver | Require renewed review of the changed record |
| Unknown payment status | Provider instruction reference and dated status | Payment operator | Investigate before preparing a replacement payment |
Handle changes to supplier and beneficiary evidence
Suppose Alder receives a second copy of AS-240 with different bank details. The amount and supplier name still match the expected invoice. The agent should preserve both versions and flag the changed beneficiary evidence. In this recommended workflow, it cannot use the revised document as sufficient authority to change the supplier's payment destination.
The supplier-master owner verifies the request through the company's established process. Once that owner records a decision, the AP reviewer checks whether the invoice proposal needs revision. A separate payment approver then reviews the instruction containing the verified beneficiary. Keeping these responsibilities distinct makes the change explainable later.
Test a less obvious variation: the invoice attachment is unchanged, but the email body asks the team to use a new account. Treat that message as source material that may require investigation, rather than an instruction granting the agent authority. The agent's financial action remains governed by the application's policy and the authorized reviewer.
These are design recommendations for your pilot, not a claim that every AP product includes a complete supplier-verification service. Ask the vendor to show how its workflow represents the exception and how it hands off to your existing owner.
Measure the work that reaches the reviewer
Measure invoice preparation separately from financial correctness. Count the documents received, proposals prepared, exceptions raised and corrections made. Then inspect the value of invoices incorrectly allowed past a required check. A fast draft that conceals a receipt mismatch is a different outcome from a slow draft that preserves the issue for review.
For a reproducible pilot, create a worksheet with one row per invoice. Include expected result, actual result, reviewer changes, unresolved reason and final record reference. Use elapsed time only if you record a clear start and end event. Do not infer time saved from the agent's response speed or copy a vendor's benefit percentage into your evaluation.
Alder's AS-240 should remain in the receipt-exception queue until the responsible person resolves the partial delivery. If the team decides to approve only part of the invoice, preserve the basis for that decision and the resulting amount. The agent should not invent a tolerance or assume that a small discrepancy is acceptable.
Also evaluate the exceptions the agent misses. A queue that contains only detected issues can make the process look effective while excluding false approvals. Review a sample of apparently ordinary proposals against the original evidence and record any controls they bypassed.
Run one controlled AP pilot
Start with one invoice channel, one destination system and a defined supplier group. Include an ordinary invoice, a duplicate, a missing order reference, the partial delivery and the beneficiary-change case. Agree on the expected result for each before the agent processes the set.
Keep the first run draft-only if the team has not evaluated posting or payment execution. This is a scope recommendation, not a statement that an agent can never receive broader authority. The next permission should follow a separate evaluation of its action, failure states and recovery process.
End the pilot with a documented decision: which task the agent can perform, which cases require review and who owns the unresolved integration questions. The detailed invoice-processing guide follows the records through to payment evidence. The controls and reconciliation guides cover the decisions on either side of that workflow.