How can we test that document automation handles credit notes differently from invoices?

Test credit notes and invoices as paired documents, then follow each result through extraction, amount handling and finance review. A pass requires the correct document type, a traceable amount interpretation and the right destination. Include cases where the correct outcome is to stop for clarification.

For a document processing workflow, the useful deliverable is a repeatable document-type branching test pack. Finance defines the expected outcomes before the automation runs; the operator records what actually happened. This prepares evidence for finance decisions without authorising payments or accounting entries.

Define what “handled differently” means

Start with a written agreement between finance and the workflow owner. Which documents count as invoices, which count as credit notes, and which evidence is insufficient? Specify separate outcomes for recognised documents, unresolved documents and suspected duplicates.

For this proposed test, use a supplier-payables perspective: an invoice has a positive proposed payable effect, while a credit note has a negative proposed payable effect. This is a testing convention, not an instruction to send negative values to every accounting system. Finance must confirm the destination’s required representation.

Record document type and amount separately. A credit note printed with a positive total should not become an invoice simply because its total lacks a minus sign. Equally, a negative figure is not enough evidence to classify an otherwise unclear document.

Azure documents extraction models and custom classifiers that identify designated document types before extraction. That supports building a classification stage; it does not establish that your samples will be classified correctly. Source: Azure Document Intelligence overview

Choose samples that expose the wrong shortcut

Select paired samples from the same supplier with similar logos, tables and total boxes. Include different suppliers too, so the test checks meaning across layouts. Use sanitised copies that retain the distinguishing evidence.

Add a credit note whose description mentions the original invoice. This tests whether the workflow mistakes an invoice reference for the current document’s identity. Also include an invoice with credit-related wording in its terms, rather than its heading.

Make controlled variants: obscure a heading, remove an original-invoice reference, or introduce conflicting labels. Mark each as a deliberate test variant and preserve the original separately. Change one feature at a time so a failure has an explainable cause.

Keep some finance-labelled examples out of configuration work. Run those unseen examples after adjustments. Otherwise, success may only show that the workflow recognises the examples used to tune it.

Preserve the evidence behind the signed amount

Require the result to retain the printed heading, document reference, referenced invoice, currency and total exactly as read, alongside any normalised values. Keep a page reference or image location so a reviewer can find the evidence quickly.

Separate the printed amount from the proposed payable effect. If both fields are called “total”, an operator cannot tell whether a minus sign came from the source or was introduced by a rule. Include an explanation such as “credit-note heading; negative payable effect under approved convention”.

A structured response can constrain field names and permitted document labels. OpenAI documents schema adherence through Structured Outputs. Schema adherence alone does not establish that a selected label matches the document, so compare every result with the finance-approved answer. Source: OpenAI Structured Outputs

Treat unreadable values as missing. Do not silently substitute zero, a prior document’s total or a guessed invoice reference.

Copy this document-type branching test pack

Purpose: Verify classification, signed effect and review routing before finance relies on extracted documents.

Test convention: All amounts and identifiers below are hypothetical. Invoice effects are positive and credit-note effects negative from a supplier-payables perspective. These are proposed test rules, subject to finance approval and destination mapping. A signed effect is a review proposal, never posting authority.

Run details: Date: ___ | Operator: ___ | Finance reviewer: ___ | Workflow version: ___ | Destination mapping version: ___ | Test destination: ___

Destinations: Map each named destination below to a test queue or explicit review status before running. Allocation hold and duplicate review must remain distinguishable from ordinary credit-note review.

Record for every case: Source file and page; expected versus actual type, printed amount, signed effect and destination; duplicate status; destination record identifier; pass/fail; reviewer decision; failure reason.

Execution checklist:

• Finance approves expected results and destination mappings before execution.
• Run each case through intake, extraction, rules and destination review.
• Inspect destination records rather than relying on success messages.
• Deny one review request and confirm no downstream financial action occurs.
• Replay a completed submission and check for additional adjustment records.
• Correct failures, then rerun affected cases and the paired ordinary examples.

Proposed acceptance rule: Every expected result matches, unresolved cases remain held, and replay creates no second proposed financial effect. A duplicate-review record is permitted; a second adjustment is not. Finance signs off the demonstrated scope and lists untested variants.

Work through ordinary, missing and duplicate cases

Using the hypothetical pack, cases A and B should produce separate review records. Finance sees the invoice’s proposed R2,400 increase and the credit note’s proposed R600 reduction. Their combined proposed effect is R1,800, but that arithmetic does not prove the credit has been allocated correctly. Inspect both document identities and their relationship.

Case D distinguishes classification from allocation. Preserve the supported credit-note classification and proposed effect, but send the record to allocation hold. The reviewer checks available records or requests clarification; the workflow must not select whichever invoice has the closest amount.

For case E, the reviewer examines the complete document, including continuation pages, before resolving conflicting labels. If the evidence remains unclear, request a corrected or clearer source. Recording “unresolved” and leaving the signed effect unset is the expected successful outcome.

For case F, change the filename and resend the document. The operator compares supplier, reference, amount and source evidence with the earlier record in duplicate review. The retained negative effect describes the document; it must not create another adjustment.

Case G checks the opposite mistake. Only the supplier changes from case A, so invoice type, printed amount, signed effect and invoice-review destination remain identical. Suppression solely because INV-410 already exists fails this case.

Verify the branch reaches the correct review queue

Run the test beyond the extraction screen. Inspect the destination record’s type, amount representation, source attachment and review status. Confirm that exceptions cannot fall through to the ordinary invoice path. Check that allocation holds and duplicate candidates remain visibly distinct.

OpenAI’s function-calling documentation describes a flow in which the application executes a model-requested function. A suggested route therefore does not prove completed routing: inspect the application’s resulting record. Source: OpenAI function calling

Test rejection and interruption too. Denying a credit-note review should leave no completed adjustment. Interrupt a test after record creation, then retry it to check whether recovery produces a second adjustment record.

These are proposed workflow controls, not automatic vendor features. Before deployment, check current product, account, plan and regional eligibility for the components chosen.

Make the handover decision from the failures

Report classification, signed-effect and routing failures separately. An overall accuracy figure can hide a credit note sent to the invoice path. Under the proposed acceptance rule, that failure blocks reliance on the affected branch until corrected and retested.

Give operators the pack, expected results and examples of resolved exceptions. Record what remains untested, such as another supplier’s format or a mixed-document attachment.

Use the AI agents versus automation comparison to decide where fixed rules are sufficient. If interpretation needs a custom AI agent, define its limited role using the custom AI agents workflow guide. Keep finance decisions explicit within the wider AI automation process.

FAQ: Testing invoice and credit-note handling

Should every credit note have a negative extracted total?

No. Preserve what is printed. Test the signed payable effect separately using the approved convention, then check the destination mapping. Never reverse an already negative amount merely because the document is a credit note.

What should happen when the original invoice reference is missing?

Keep a supported credit-note classification, but route the record to allocation hold under this proposed workflow. Finance investigates the missing relationship; the system should not invent it.

Is a correct document label enough to pass?

No. The amount interpretation, duplicate handling and resulting review record must also match expectations. A correctly labelled credit note can still reach the wrong destination.

If your business needs a repeatable test pack for invoice and credit-note processing, get in touch to scope the samples, expected results and finance handover.

Sources

• Azure Document Intelligence overview
• OpenAI Structured Outputs
• OpenAI function calling