Start with an invoice whose evidence is incomplete
AI invoice processing is easiest to evaluate when the test includes a document that should not move straight through. Our fictional buyer, Alder Supply, receives invoice AS-240 for 24 components at $100 each. Purchase order PO-80 requests those 24 components, but the receiving record confirms only 18. The invoice total is $2,400, and the receipt difference is six components.
The agent's first job is to extract the invoice information, connect the correct order and present the mismatch. It should not treat a correct total as proof that the entire invoice can proceed. The test is synthetic and makes no tax, discount or freight assumption; those fields would need their own evidence in a real invoice.
Define the destination record before the pilot. A purchase document draft, an unposted purchase invoice and a posted invoice represent different stages. The agent's completion message should identify which record it created. Otherwise an operator may read “invoice processed” as approval or posting when the actual output is only a proposal.
The diagram follows AS-240 through the records that support a payment decision. It is a recommended operational map, not a promise that one product performs every stage or that every organization uses the same approval policy.
AS-240 through the invoice and payment records
- Invoice
24 components at 100 USD; total 2400 USD.
- Purchase order
PO-80 requests 24 components from the identified supplier.
- Receipt
Only 18 components recorded; six require investigation.
- Invoice review
Owner resolves the difference and reviews the resulting version.
- Payment instruction
Authorized operator reviews the separate beneficiary and amount.
- Reconciliation
Connect provider evidence to the obligation; retain unresolved states.
Capture the document without inventing missing values
Retain the original invoice and a stable source reference. Extract the supplier identity, invoice reference, dates, currency, line quantities, prices and total where they are present. Record missing or uncertain values explicitly. If the date cannot be read, the upload timestamp is useful metadata but not necessarily the invoice date.
Check arithmetic using the extracted lines. In AS-240, 24 multiplied by $100 equals $2,400. If a line total or invoice total disagrees, the proposal should preserve the discrepancy. An agent should not silently choose the total that best fits the purchase order or change a quantity to make the calculation balance.
Distinguish extraction from interpretation. The document may say “components,” while the purchasing system uses an internal item number. Mapping between them requires evidence. A matching description can support a candidate, but a reviewer should be able to inspect the item and unit of measure before accepting the association.
The annotation table shows how a useful review record explains each field's purpose. It also marks the beneficiary request as separate from invoice capture. A scanned invoice is not sufficient authority to change an established supplier's payment destination.
What the reviewer should see beside each field
Scroll the table to compare all columns.
| Field | Synthetic value | Why it matters | Review response |
|---|---|---|---|
| Invoice reference | AS-240 | Connects the source and possible duplicates | Preserve across every stage |
| Currency | USD | Defines the amount and any later payment currency | Keep currency attached to every amount |
| Quantity | 24 components | Must be compared with order and receipt | Flag six-component receipt difference |
| Unit price | 100 USD | Supports the invoice arithmetic | 24 × 100 = 2400 USD |
| Receipt quantity | 18 components | Shows recorded delivery evidence | Receiving owner investigates |
| Tax | No tax assumption in this teaching example | A real invoice requires source values and applicable treatment | Reviewer checks the original fields and accountant-defined policy |
| Beneficiary request | Changed bank details in a new message | Separate master-record decision | Do not replace verified destination automatically |
| Draft status | Prepared for review | Describes the record actually created | No posting or payment implied |
Match the supplier, order and receipt separately
Begin with supplier identity. If the invoice names an unfamiliar legal or trading name, the agent should show the candidate master record and the supporting evidence. Creating a new supplier, approving that supplier and paying it are different decisions. A quick match based only on a similar name can propagate into later records.
Then compare the referenced order and line details. For AS-240, the order confirms 24 components at the stated price. The receiving record confirms 18. The order match explains the intended purchase, while the receipt shows what has been recorded as delivered. Keeping both references is essential to the exception.
Microsoft documents Payables Agent proposing purchase-order matches, with Business Central performing compatibility and receipt validations. Its order-match documentation distinguishes these deterministic warnings from AI confidence and separates draft finalization from posting. The agent does not post the invoice. [3]
Use that distinction in the evaluation. A warning about quantity is a system validation result, rather than a measure of how certain the model feels. Ask the vendor or integration team which checks belong to the ERP and which are agent suggestions. The operator needs to understand both before deciding how the workflow proceeds.
Resolve the six-component difference with its owner
The agent should route AS-240 to the receiving and AP owners with a concise explanation: invoice quantity 24; recorded receipt 18; difference six. Include the order and receipt references. This gives the owner a concrete issue to investigate without rereading the entire task conversation.
Several explanations are possible. The remaining components might have arrived without a recorded receipt, the supplier might have invoiced early, or the invoice might be wrong. The agent should not select an explanation merely because it would allow the task to finish. The responsible person determines what happened and records the relevant evidence.
If a new receipt is recorded, prepare a revised proposal that refers to it. If the supplier issues a correction, retain the original invoice and the correction relationship. If the organization authorizes another treatment, preserve the decision and resulting amount. The guide does not prescribe a universal tolerance or accounting treatment.
An approval should refer to the reviewed version. If the quantity or amount changes after review, compare the revised proposal with the earlier decision and request the review required by the owner's policy. Keeping that connection avoids treating an old approval as open-ended permission.
Keep invoice approval distinct from payment authority
Microsoft's Payables Agent overview describes finalizing a draft into an unposted purchase invoice. It explicitly separates this step from approval workflows and posting. That documentation supports evaluating invoice preparation; it does not establish autonomous bank payment. [1]
In Alder's recommended workflow, the AP reviewer approves the appropriate invoice treatment after the receiving exception is resolved. The authorized payment operator then prepares or reviews a separate instruction. That instruction identifies the payer account, beneficiary, amount, currency and approved obligation.
If the supplier asks for changed bank details, the supplier-master owner verifies the change through the established process. The invoice agent can collect the request and flag the difference, but the document itself should not expand the agent's authority. An approval of AS-240 does not automatically approve a newly supplied beneficiary.
Also inspect how the payment system checks duplicates. A repeated invoice email, repeated agent request and repeated bank instruction are different identity problems. Preserve the references that connect them, and test whether retrying one stage creates an unintended second record at another.
Track system states without simplifying uncertainty away
A useful status sequence names the actual record: source received, draft prepared, exception awaiting review, unposted invoice created, posting recorded and payment instruction submitted. Use only the stages your implementation supports. Do not invent provider status names or imply that every stage is automatically performed.
The payment provider may return a state that requires later observation. Preserve its wording and timestamp in the evidence record. An accepted instruction is not automatically evidence of final settlement. When the meaning is unclear, ask the integration owner to interpret the documented provider status before the agent closes the obligation.
If a tool times out, retain the unresolved operation reference. A new attempt should not be treated as fresh work until the team knows what happened to the original operation. For a draft, recovery might involve locating or withdrawing it. For a submitted instruction, the response depends on the provider's supported investigation process.
Supervision also needs a usable stop path. Microsoft documents reviewing agent activities and stopping tasks. In your pilot, test what stopping actually prevents and which records remain for review. Stopping the agent's future work does not prove that an already submitted external action was canceled. [2]
Test five invoice cases before broader access
Use AS-240 as the partial-receipt case, then add four variations. A clean invoice has complete matching evidence. A repeated copy has the same supplier and invoice identity. An ambiguous supplier lacks enough identity evidence. A beneficiary-change request tries to introduce a new destination. The expected result should be written before the run.
For the clean case, expect a traceable draft with correct values. For the duplicate, expect a connected exception rather than a second obligation. For the ambiguous supplier, expect a request for review. For the beneficiary change, expect a handoff to the master-record owner. For AS-240, expect the six-component difference to remain visible.
Keep the test record granular. Record extracted-value errors, incorrect order associations, missed exceptions and unauthorized actions separately. A single pass/fail label can hide whether a draft was financially correct but poorly evidenced, or well explained but attached to the wrong supplier.
Check the outputs directly in the destination system. An agent's message saying it created a draft should match a real draft reference in the pilot environment. A claimed approval should match the authorized review record. If the integration cannot provide that evidence, record the gap instead of assuming the narrative is accurate.
Finish with a decision about one workflow
The acceptance pack should contain the source set, expected outcomes, produced drafts, reviewer changes and final system references. Have someone who did not configure the agent reconstruct AS-240 from invoice through exception and resolution. This independent pass reveals whether the evidence is usable outside the original operator's memory.
Report results with their actual scope. A synthetic five-case check shows whether the configured workflow handles those cases. It does not establish a general accuracy rate, fraud-prevention result or processing-time benefit. Measuring those outcomes would require a defined evaluation method and observed data.
Decide which task is ready for a bounded pilot and which permissions remain excluded. For Alder, the evidence may support draft preparation while posting and payment continue through the existing authorized process. The AP category guide maps that division; the reconciliation guide explains how later payment evidence connects to the obligation.
Keep the test available after launch. New supplier formats, purchasing arrangements and integration changes can introduce failures that the initial set did not contain. Add those cases to the expected-outcome worksheet and repeat the relevant checks before expanding authority.