One AI spend queue still needs three control boundaries

One interface can hide several different truths

A purchase request says what someone wants. A purchase order says what the company committed to buy. A receipt says what arrived. An invoice says what a supplier claims. An expense says what an employee paid. An ERP posting says what Accounting recognized. A bank line says what cash actually left. Putting them in one queue helps only if the queue preserves those differences.

Finofo's September 9 release is a useful signal of where spend software is moving. The company expanded from accounts payable into expense management and purchasing, advertising one queue, one approval model, and one posting path for invoices, card spend, claims, purchase orders, payments, and reconciliation. The product announcement is first-party marketing, not independent proof of control effectiveness. Its importance is the architecture it makes visible: AI-assisted spend products increasingly span the whole path from intent to cash.

Current practitioner discussion supplies the caution. In a September 8 procurement thread, the highest-rated response argued that procurement is too cross-functional to place on autopilot. A separate September vendor thread expressed skepticism that new tools solve tail spend. Older but concrete Accounting and NetSuite discussions repeat the same operational point: faster visibility or OCR does not repair missing POs, inconsistent coding, retroactive approval, closed orders, duplicate submissions, or absent receipts.

ERP documentation shows why. Microsoft Dynamics distinguishes two-way, three-way, total, charge, and cumulative price matching, with tolerances and explicit choices about whether discrepancies block workflow or posting. SAP Concur supports different rule groups for POs with receipts, POs without receipts, and receipt confirmation. Those are not implementation details to collapse into a generic “AI confidence” score. They encode different obligations and evidence.

The practical thesis is that a unified interface should create one linked case, not one undifferentiated approval. Keep three release boundaries: commitment, accounting, and payment. Let AI normalize documents, search for links, and assemble exception evidence. Let deterministic rules prove arithmetic, duplicates, tolerances, authority, and segregation. Let named people own the decisions that create an obligation, recognize it, and release cash.

Keep commitment, accounting, and payment separate

The first boundary is commitment. Before a supplier is instructed or a card purchase is made, the organization decides whether the need is legitimate, budgeted, competitively sourced when required, contractually acceptable, and approved by someone with current authority. An after-the-fact invoice approval cannot recreate this control. A familiar approver clicking “approve” does not prove that the purchase was allowed before the company committed.

The second boundary is accounting recognition. AP verifies that the right entity received a real obligation, the supplier and document are authentic, the goods or service evidence supports it, the amounts and taxes recalculate, the coding and period are correct, and no duplicate or credit relationship makes the liability wrong. The reviewer approves a specific bill or journal proposal, not an abstract vendor relationship.

The third boundary is payment. Treasury or AP prepares an exact batch from approved liabilities, current bank details, holds, credits, discounts, value dates, cash needs, currency, and signer rules. Authorized signers release the exact batch. The resulting bank and ERP records are reconciled. Supplier creation, bank change, invoice approval, payment preparation, and payment release should not silently converge on one person or one autonomous agent.

Build a linked case without erasing source identity

One spend case can connect a request, quote, contract, PO, receipt, invoice, card transaction, employee claim, credit, posting, payment, and bank line. Every node keeps its native system ID, timestamp, owner, version, and source hash. The case stores proposed edges such as “invoice bills PO,” “receipt fulfills line,” or “card charge duplicates claim.” A proposed link becomes accepted only after its control-specific test passes.

case_id: p2p-2026-0911-0042
legal_entity: example-services-uk
supplier_id: SUP-01892
artifacts:
  request: PR-4421@sha256:...
  purchase_order: PO-20291-v3@sha256:...
  receipt: SR-8841@sha256:...
  invoice: INV-88917@sha256:...
  card_candidate: CARD-55102@sha256:...
links:
  - from: INV-88917
    to: PO-20291-v3
    type: bills
    status: proposed
controls:
  supplier_identity: verified
  duplicate_cross_channel: exception
  three_way_match: blocked
  accounting_release: blocked
  payment_release: blocked

This record prevents two common mistakes. First, the AI cannot rewrite an invoice field and make the original disappear. It can propose that “Acme UK” maps to supplier SUP-01892, while the reviewer still sees the exact source. Second, a single green badge cannot hide a red control. An invoice may pass arithmetic and still fail receipt, supplier, approval, or duplicate checks.

Use explicit states. “Matched” should never mean “the model found something similar.” It means the declared policy, fields, tolerances, and evidence produced a reproducible result. Missing is different from mismatch. A service receipt that has not yet been confirmed is missing; a confirmed quantity of eight against an invoice for ten is a mismatch. The next owner and permitted resolution differ.

Search for duplicates across channels before matching the happy path

Unified spend increases duplicate risk before it reduces it. The same obligation can arrive as a supplier invoice, card charge, employee expense, recurring debit, forwarded PDF, OCR retry, consolidated statement, or credit-and-rebill. An exact invoice-number rule catches only a subset. Supplier systems reuse number formats, punctuation changes, and fraudsters alter small fields.

Build a deterministic candidate set using normalized legal supplier ID, amount, currency, invoice date, service period, PO, line fingerprints, bank destination, and prior payment. Add fuzzy signals for similar numbers, near amounts, duplicate documents with altered metadata, and line-level overlap. AI may explain why two records look related, but a person resolves ambiguous installments, consolidated invoices, deposits, credits, and recurring charges.

duplicate_key_exact = hash(
  legal_entity,
  supplier_master_id,
  normalize(invoice_number),
  currency,
  decimal(total)
)

candidate_if = (
  same_supplier and same_currency and
  (same_amount or overlapping_lines or same_po) and
  days_between(invoice_dates) <= policy_window_days
)

block_if = exact_key_exists or prior_payment_matches
review_if = candidate_if and not documented_credit_rebill

Only then apply the right commercial match. A two-way match compares invoice price and amount to the PO. A three-way match adds received quantity. Service work may use approved milestones or named service confirmation. Non-PO expenses need a different policy, not a fabricated PO. Cumulative checks matter when several invoices bill one PO line. Charges, tax, freight, discounts, and partial receipts need their own logic.

Tolerances are policy decisions. A 2% price variance may be acceptable for one category and prohibited for another. Quantity underbilling can be as important as overbilling because it may conceal a partial delivery or shift an accrual. Microsoft documents options that merely warn and still permit posting; a reviewer must know whether the system blocked the transaction or displayed an icon that someone ignored.

Worked example: the invoice is correct and the payment is still wrong

A marketing team receives an approved PO for £24,000 of services, billed in three £8,000 milestones. The supplier emails the first invoice. A project manager forwards it to AP and also pays it on a corporate card to keep work moving, then submits the card receipt as an expense. The supplier later sends the same PDF to the centralized invoice address.

Each individual item looks plausible. The invoice matches the PO and milestone. The card transaction has a receipt and business purpose. The second email has the same invoice number. A document-only process catches the repeated PDF but may miss that the card already settled the obligation. A card-only process sees an approved expense. A unified case searches every channel before release.

The engine creates three candidate records under one obligation. Exact document hashing links the two PDFs. Supplier, amount, date, PO, and line description link the card charge. AP verifies the supplier and invoice, the receiving owner confirms milestone one, and the budget owner confirms the original commitment. Accounting records the service expense and clears the card liability; it does not create a second trade payable. The emailed invoice is marked already settled, and payment is blocked.

The case retains every source, reason, reviewer, and status. If the supplier claims non-payment, AP can show the payment path without deleting the invoice. If the card charge is later reversed, the case reopens and the payable can be reassessed. Closure represents a reconciled consequence, not an AI label.

Exceptions need owners, clocks, and permitted resolutions

An exception queue is useful only when each class has a control objective and owner. A missing receipt belongs first to the receiving or service owner. A price variance belongs to procurement or the contract owner. A tax-code question belongs to qualified tax or Accounting staff. A bank change belongs to supplier-master and fraud controls. A stale approval returns to the current delegated approver. AP should not become the universal owner merely because the invoice arrived there.

Set service clocks by consequence. A routine missing receipt may wait. A potential account takeover or urgent bank change requires immediate security and bank contact. A discount deadline can justify priority but cannot weaken identity or authority checks. Escalation changes who reviews; it does not turn missing evidence into approval.

Approve exact artifacts, then reconcile the real consequence

Accounting approval should identify the invoice or journal hash, legal entity, supplier, period, amount, currency, coding, tax, match result, exceptions, and reviewer authority. If any material field changes, approval expires. The same rule applies to payment. Signers review an exact batch and bank destination, not yesterday's spreadsheet or a summary card that can drift from the executable file.

ICAEW's current invoice-fraud guidance emphasizes independent supplier verification, segregation between vendor setup, invoice approval, and payment, plus duplicate and anomaly review. That separation is especially important when AI can move information across systems quickly. Credentials and payment execution should remain outside the model's reach; the agent submits a proposal to a deterministic service that checks policy and named approval.

After release, match the bank statement and payment confirmation to the approved batch and ERP open item. Confirm amount, currency, fees, FX, date, payee, settlement, and residual balance. Failed payments, partial settlements, discounts, credits, and bank fees create new exceptions. “Payment sent” is not closure. Closure means the approved liability was settled once and the books and bank agree.

Common failure modes

A 30-day pilot should start with exceptions

Choose one legal entity, one ordinary spend category, and a historical population containing known duplicates, partial receipts, non-PO invoices, credits, card overlap, price variances, bank changes, rejected payments, and late approvals. Freeze the population and reviewer decisions. Do not begin with live payment authority.

During week one, map authoritative systems, control states, delegation, tolerances, owners, and evidence. During week two, run AI extraction and link proposals in shadow mode; compare them with deterministic matches and human conclusions. During week three, let the system prepare exception packets while people continue existing approvals. During week four, permit a narrow, low-risk posting path only if identity, duplicate, matching, authority, and audit evidence meet threshold. Keep payment read-only until the separate release and reconciliation controls pass drills.

Measure population completeness, field accuracy, exact and fuzzy duplicate precision/recall, match accuracy by spend type, false auto-clear rate, exception aging, reviewer correction, first-pass resolution, time to posting, payment rejects, reconciliation breaks, and incidents. The most important metric is not touchless percentage. It is the rate at which a transaction that should have been blocked reached posting or cash.

• Freeze originals and system IDs before AI processing.
• Test cross-channel duplicates, not invoice-number duplicates alone.
• Reperform arithmetic and match logic deterministically.
• Prove current delegation and segregation on the exact artifact.
• Route every exception to a named fact owner.
• Keep supplier-bank change and payment release outside autonomous authority.
• Reconcile bank and ERP before closing the case.
• Stop the pilot if population completeness or block effectiveness is unknown.

FAQ

What is an AI procure-to-pay exception workflow?

It is a linked evidence process across request, PO, receipt, invoice or expense, approval, posting, payment, and reconciliation. AI prepares evidence and proposed links; deterministic controls and authorized people decide release.

Can a perfectly matched invoice be paid automatically?

Only if policy allows and the system separately proves supplier identity, duplicate status, authority, bank details, payment holds, batch integrity, and segregation. A commercial match is necessary for some invoices but is never the whole payment control.

Does one platform become the source of truth?

It can become the control case, but source authority remains distributed. The PO system owns the commitment record, receiving owns delivery evidence, the supplier master owns controlled identity, the ERP owns the posting, and the bank owns cash settlement.

Where should AI have the most autonomy?

In reversible preparation: intake, classification, candidate linking, arithmetic, explanation, and exception packet assembly. Autonomy should narrow as the workflow approaches supplier changes, accounting posting, external communication, and payment.