# Invoice automation: evidence worksheet

Kognitos evaluation aid · October 25, 2026

All six cases use invented inputs and proposed test rules. No connected Kognitos run, customer result, certification or measured performance is represented. This is a manual evaluation aid, not an import file or an executable automation.

## Prepare the evaluation

Use the same cases to compare the current process and each shortlisted platform. Recreate the records in your agreed test environment; do not assume these CSV columns match your ERP or automation input format. Download the [source documents and setup guide](https://www.kognitos.com/solutions/finance-automation-solutions/invoice-evaluation/source-documents.zip): 17 fictional PDFs with matching text copies. T03 intentionally has no receipt. Follow the setup guide for T04's real prior test posting, T05's controlled input fault and T06's actual ERP rejection. These simplified files do not measure extraction accuracy on scans. The CSV deliberately specifies expected outcomes separately from actual outcomes.

Example scope: one currency (USD), a unit price of $10, no tax or freight, and no allowed quantity or price variance. Validate source fields, require the matching receipt and screen for prior invoices. Agree the actual approval policy, permissions and posting action with your process owner. A clean match is only eligible for posting after all required approvals; it is not permission to bypass them.

Each case is independent. Use the supplied identifiers or retain a mapping to your test IDs. T04 deliberately repeats its own previously posted supplier/invoice identifier; it is independent of T01. Keep its prior ERP document reference. For T06, arrange a known rejected posting in the test environment and verify the actual error returned. Do not substitute an invented error message.

Download the [six test cases](https://www.kognitos.com/solutions/finance-automation-solutions/invoice-evaluation/test-cases.csv). Blank receipt quantity in T03 means missing evidence, not zero received units. T05 intentionally makes the extracted total $10,000 while the source document and its line arithmetic total $1,000.

## One record per case and run

Copy this table for T01–T06. Leave status as Not tested until the case has run. Replace blank fields with observed evidence, not the expected answer.

| Evidence field | Actual value or record reference |
|---|---|
| Case ID, run ID and timestamp/time zone | |
| Platform, environment, integration and ERP version | |
| Test status: Not tested / Pass / Fail / Blocked | Not tested |
| Original invoice, PO and receipt identifiers and retained versions | |
| Extracted fields; source comparison; corrections and who made them | |
| Calculation, currency and treatment of tax/freight | |
| Approved English procedure or equivalent rule; version and approval reference | |
| Exception reason, assigned reviewer and requested resolution | |
| Human decision, timestamp, authority and supporting evidence | |
| Requested ERP action and request/correlation identifier | |
| Actual ERP response: held, rejected, posted or unknown; returned error | |
| Posted ERP document ID, only when returned and verified | |
| Expected versus actual outcome and explanation of any difference | |
| Evidence locations, access permissions and retention requirements | |
| Resolution retained only for this case, or proposed for reuse | |
| Reuse approval/version and positive/negative retest references | |

## Review each result

- T01: verify source agreement, approvals and the returned posting status/document ID. A completed automation alone does not prove an ERP posting.
- T02: the invoice is 100 × $10 = $1,000; received goods are 96 × $10 = $960. The $40 difference should be held under this example's rule. Preserve the source values and record the review decision.
- T03: preserve the missing-receipt state and demonstrate the agreed review path. Do not invent a receipt or treat missing data as a clean match.
- T04: show the prior invoice/posting and demonstrate that a second posting is prevented under the agreed test rule.
- T05: compare the extracted $10,000 with the $1,000 source total. Record the correction and authority before any later permitted action. Correct arithmetic on a wrong extracted value is insufficient.
- T06: retain the actual ERP rejection. Do not mark the invoice posted because the workflow reached its last step. Verify posting state before any authorized retry.

A correctly held or rejected case may pass its control test without being a successful posting. Count these outcomes separately. If a resolution becomes reusable guidance, inspect its scope and approval, then test one case where it should apply and one where it must not. Retain both runs; accepting one resolution does not prove that every future exception is covered.

## Compare operating results

Record attempted/completed/blocked cases, correct outcomes, manual touches, exception-resolution time, evidence-reconstruction time and full operating cost on the same case set. State sample size, environment, time period and excluded steps. These six functional tests are not a production throughput, accuracy or ROI benchmark.

## Sources and next steps

- [Finance evaluation and illustrated mismatch](https://www.kognitos.com/solutions/finance-automation-solutions/#invoice-evidence-example).
- [Exception handling and reusable guidance](https://www.kognitos.com/videos/kognitos-operations-exception-handling-learnings/).
- [Kognitos Guidance Center](https://docs.kognitos.com/guides/platform/guidance-center).
- [Kognitos Troubleshooting Guide](https://docs.kognitos.com/guides/platform/automations/troubleshooting-guide).

The linked pages explain the evaluation and documented guidance workflow. The six-case dataset and suggested acceptance criteria are illustrative evaluation design, not product execution evidence.