Invoice exception queue for payment decisions

Use one fixed queue for each invoice batch. It gives accounts payable a clear set of records to progress, hold or send back for evidence, rather than a summary that leaves the next action unclear. This works for operations and AP leads who need to review invoices against purchase orders, receiving notes, approvals and supplier emails.

The aim is not for the model to authorise a payment. It is to prepare a traceable decision queue for the person with payment authority.

1. Set the batch boundary

Before you upload or paste anything, create a batch cover note. Give it a batch ID, such as AP-2026-08-21-A, and state:

• the invoice date range
• the supplier names or supplier IDs included
• the business unit or entity
• the payment run being prepared
• the systems or folders used as evidence
• the review owner and escalation owner

Keep one invoice record per invoice number, even where a supplier sends several PDFs in one email. If an invoice has a credit note, list it as a linked document, not as a replacement invoice.

Use approved storage and access controls for supplier bank details, tax records and correspondence. Do not paste unrelated emails or personal data merely because they are nearby in the mailbox.

2. Prepare a consistent evidence pack

For every invoice, provide the same fields where available. A spreadsheet export is usually easier to review than screenshots. Include the source document name next to each record so that a reviewer can find it again.

Build four inputs:

1. Invoice register: supplier name and ID, invoice number, invoice date, due date, currency, net amount, tax amount, gross amount, purchase order number and bank-detail-change flag.
2. Purchase order register: PO number, supplier ID, ordered lines, quantities, unit prices, total value, requester, approver and PO status.
3. Receiving register: PO number, receipt or goods-received number, received date, quantities received, service-confirmation reference and receiver.
4. Correspondence and approval log: invoice number or PO number, email date, sender, approval status, dispute status, delivery issue and agreed next action.

Normalise obvious formatting differences before review. For example, use one date format and remove spaces from invoice numbers only if your source systems treat those spaces as non-significant. Preserve the original value in a separate field where possible.

If your file set is large, split it into manageable batches by entity or supplier group. File handling and available limits depend on the version and setup you use. Check the relevant guidance in the xAI documentation overview before setting a batch size.

3. Give the model a queue schema

Ask for a table or CSV-style output with fixed columns. Fixed fields make the result usable in a payment-control meeting and make omissions visible.

Use this instruction, replacing the bracketed text:

Review the attached invoice, PO, receiving and correspondence records for batch [batch ID]. Do not approve payment. Create one row per invoice.

Use only these statuses: READY_FOR_REVIEW, HOLD_MISMATCH, HOLD_DUPLICATE, HOLD_MISSING_APPROVAL, HOLD_MISSING_EVIDENCE, VENDOR_FOLLOW_UP, or ESCALATE.

Return these columns: batch_id, supplier_name, supplier_id, invoice_number, invoice_date, currency, gross_amount, po_number, receipt_reference, status, exception_type, evidence_found, evidence_missing, comparison_result, recommended_next_action, action_owner, source_document_names, and confidence_note.

Match supplier ID, invoice number, PO number, currency, line quantity, unit price and total where those fields exist. Flag uncertainty rather than inferring missing facts. Treat possible duplicates as holds. Quote the specific conflicting values and source document names in comparison_result.

Ask it to retain every invoice from the register, including invoices with no matching PO or receipt. The queue is incomplete if it contains only clean matches.

4. Apply simple status rules

Use a small status set. It prevents each reviewer from inventing their own wording for the same problem.

If you see this	Set this status	Put this next action in the queue
Supplier, invoice number, amounts, PO and receipt agree, and approval is recorded	READY_FOR_REVIEW	Route to the named payment approver
Same supplier and invoice number, or materially matching number and amount, appears more than once	HOLD_DUPLICATE	Compare document images and payment history before any release
PO, receipt, quantity, price, tax or currency conflicts	HOLD_MISMATCH	Name the conflicting fields and send to the PO owner or buyer
No recorded approval for a required invoice or PO	HOLD_MISSING_APPROVAL	Request approval from the recorded approver or delegate
No PO, receipt, service confirmation or readable invoice is available	HOLD_MISSING_EVIDENCE	Locate the missing record and assign its owner
A supplier must confirm delivery, credit, corrected invoice or bank details	VENDOR_FOLLOW_UP	Draft a factual query with invoice and PO references

Use ESCALATE for cases that cannot safely be classified, such as conflicting supplier identity, an unexplained bank-detail change, or correspondence indicating a dispute. State why it needs escalation. Do not combine several different holds into READY_FOR_REVIEW merely because the invoice is due.

5. Check the queue before using it

Do a short control check before the payment meeting. Start with reconciliation, then test the decisions.

• Count invoice-register rows and queue rows. They must match, except for documented voids or duplicates in the source register.
• Filter the queue for blank status, action_owner or source_document_names fields. Resolve each blank.
• Select a small sample from READY_FOR_REVIEW. Open the invoice, PO, receipt and approval record yourself. Confirm the invoice number, supplier, currency and gross amount.
• Select every HOLD_DUPLICATE row. Confirm that the possible duplicate was identified using more than a shared supplier name.
• Check that a credit note is not being treated as a payable invoice.
• Compare the total gross amount by status with the invoice register. Investigate unexplained differences.

The output is wrong when it invents a receipt reference, calls an unmatched invoice ready, confuses a supplier name with a supplier ID, or reports a match without naming the documents used. It is also wrong when a queue row says only “check approval” without identifying whose approval is missing and where it was looked for.

6. Run the same close-out routine each batch

After the authorised reviewer has acted, add a final field such as final_disposition: released, held, rejected, credited or escalated. Record the decision date and decision maker in your controlled system.

Keep the queue with the batch cover note and source-document list. At the next review, reuse the same schema and status rules. This makes recurring supplier issues visible, such as repeated missing receipts or invoices that arrive before service confirmation.

When the queue does not work

If the output merges invoices, misses rows or produces vague explanations, stop using that result as a payment-control record. Reduce the batch, supply the invoice register first, and require the fixed schema again. If the source records disagree, do not ask the model to choose the true value. Put the invoice in ESCALATE, attach the conflicting references, and have the responsible AP, procurement or operations owner resolve the underlying record.