The engine is deterministic. The same supported input produces the same findings. Money is calculated in integer minor units.
Payment checks
Records are grouped by normalized legal entity, supplier, currency and invoice reference. With a consistent invoice total, a candidate is produced when net settled allocations exceed that total. Reversal rows subtract from the net. Without a total, repeated equal amounts across distinct payment IDs are review candidates.
Identical export records are excluded with a warning. Split allocations within a payment are combined before comparing repeated transactions. Conflicting invoice totals suppress a financial finding. Different legal entities, supplier spellings and currencies stay separate.
Credit checks
The current supplier open-credit reference is compared with the ledger’s remaining balance. Missing references and positive balance differences become review candidates. Duplicate statement snapshots are rejected. The user must align cutoff dates and supplier/entity names.
What is outside the scope
This version does not read PDFs, connect to accounting systems, detect fraud, validate contracts, reconcile tax, identify negotiated discounts, detect all near-match invoices, or determine legal recoverability. It cannot see records you do not provide.
Evidence and totals
Each finding includes its input rows and reason. Payment candidates and credit candidates are reported separately because they may overlap. Currencies are not converted. User-marked recovery is labeled as user-reported, not independently verified.
Why this category exists
Established providers describe duplicate payments and unapplied credits as common AP recovery work. That supports the relevance of the workflow, not a promise about any CreditLatch customer’s result. See PRGX’s recovery audit guide and Basware’s statement-reconciliation overview.