# Put subtotal and payable total next to each other

Test field selection with several plausible amounts in the same region. A parser that reads the digits correctly can still choose the wrong business value.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Create a deliberate ambiguity

Build a synthetic invoice with subtotal, tax, credit and amount payable arranged closely together. Give each amount a distinct value so a test can identify which label the extractor associated with it.

For example, use subtotal AUD 800, tax AUD 80, credit AUD 30 and payable AUD 850. These figures describe only the fixture's printed relationship. They are not a rule for every invoice or tax treatment.

Include the expected value and page region for each field. A test that checks only whether all four numbers appear somewhere in the output will miss a swapped mapping.

## Change layout while preserving meaning

Move the payable amount below a page break, repeat the subtotal in a summary box and place a previous balance nearby. These variations test whether the extractor follows labels and structure rather than choosing the largest or last amount on the page.

Use digital and scanned versions where those inputs are supported by the product. Keep image quality changes separate from layout changes at first so a failure can be attributed to a specific condition.

Do not make every fixture artificially difficult. Include ordinary supplier layouts to verify that a fix for the edge case does not degrade common documents.

## Pass the result through the real validator

Inspect raw extraction, normalised fields and validation decisions. If the wrong payable amount is selected, determine whether arithmetic catches it and whether the record is prevented from automatic acceptance.

Add a case where two wrong fields still reconcile. For instance, selecting a subtotal from one repeated summary and an adjustment from another may produce a plausible total. This demonstrates the limit of arithmetic as a standalone defence.

Test missing currency and an absent credit field. The application should preserve uncertainty rather than silently assuming values that make the equation balance.

## Check the review experience

Open the failed case in the reviewer interface. Confirm it highlights the selected source regions and explains the contradiction. The reviewer should be able to correct the field mapping without retyping the entire invoice.

After correction, verify the saved record retains both the original extraction and the reviewed value. Then inspect the downstream payload to ensure it uses the accepted field, not an older cached extraction result. The test is complete when the incorrect selection is detected or safely reviewed all the way through the posting boundary.

## Sources

- [Microsoft Learn: invoice extraction](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/invoice?view=doc-intel-4.0.0)
- [Microsoft Learn: extraction confidence](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/concept/accuracy-confidence?view=doc-intel-4.0.0)