+40.8M
Cancelled invoices
A clean-up filter dropped the reversal lines, so cancelled invoices counted as spend.
Eternity Verum
Your pipeline tests can't tell right from wrong.
Tests generated from a mapping inherit its blind spots. Verum reads the mapping you already have, asks only the questions that change the number, and proves every figure against source, without reading a line of your pipeline's code.
Tests generated from the mapping
Verum
Correct pipeline
2 of 3 red
false alarms on numbers that are right
All clear
0 false alarms
Pipeline with 9 hidden bugs
2 of 3 red
the same answer as above
8 of 9 caught
the 9th declared untestable, not missed
The bugs live in what your mapping never says.
A mapping records which column feeds which. It rarely records which rows count, in which currency, or what happens to a late invoice. Four of the bugs from our test run:
−11.0M
Ledger currency
The ledger amount is empty when an invoice is already in ledger currency. Summing that column quietly dropped every domestic invoice.
+38.9M
Prepayments
Advances to suppliers were counted as spend, on top of the invoices they paid for.
−16.8M
Late-arriving rows
The nightly incremental load skipped invoices that arrived after their month closed.
Differences in ledger currency against the correct total, on the synthetic Oracle Payables test datamart.
Three steps, no SQL.
- 1
Connect source and target
Point Verum at your raw layer and your reporting tables. Both are read where they live. Nothing is copied.
- 2
Ask in plain words, with your mapping
Upload the source-to-target mapping you already maintain. Verum asks only the questions it leaves open, and shows how much each answer moves the number.
- 3
Lock it and run it
Each check recomputes the expected value from source, compares it with your report, and opens straight to the rows behind every difference.
It asks the question a senior tester would.
Before asking, Verum measures whether the answer matters. If every option gives the same number, it doesn't ask. If they differ, you see by how much, then decide.
Every check states what it does not cover. A pass that silently skipped the hard part is worse than no check at all.
You
Verify AP spend by supplier and month matches the spend report.
Verum
Which distribution lines count as AP spend?
Including withholding and prepayment lines moves the total by 0.3M.
Item and tax lines onlyAll linesItem lines only
Not tested by this check
- Supplier names, which come from a different table
- Open payables, which need their own check
The test run, bug by bug.
Nine bugs planted in an Oracle Payables datamart. A check counts as a catch only if it passes on the correct pipeline and fails on the broken one. Verum asked three questions in total.
| Planted bug | Kind | Tests from the mapping | Verum |
|---|---|---|---|
| Join that double-counts | mechanical | — | caught |
| Unmatched suppliers dropped | mechanical | — | caught |
| Late rows never loaded | mechanical | — | caught |
| Two current versions of a supplier | mechanical | — | caught |
| Reversal lines filtered out | business rule | — | caught |
| Ledger amount without its fallback | business rule | — | caught |
| Prepayments counted as spend | business rule | — | caught |
| Withholding netted into spend | business rule | — | caught |
| Supplier history rewritten | business rule | — | declared untestable |
| False alarms on the correct pipeline | 2 of 3 checks | none |
Reads in place
Your source and target stay where they are. Verum queries them read-only and copies nothing.
Never reads your pipeline's code
Expected values come from source by a simpler path. Re-implementing your SQL would re-implement your bugs.
Says what it didn't test
Every check lists its limits next to its verdict, so a green light means what it says.