Good checks start with the right grain of data: a settled payment allocated to a specific invoice, or one remaining balance on a credit memo.
Payment file
Use a payment-allocation report from your accounting system. An invoice register alone does not prove payment. A bank export alone usually lacks the invoice reference. Combine or export these records in your accounting workflow before importing.
| Column | What it means |
|---|---|
| entity | The legal entity that paid. Keep distinct clients separate. |
| vendor | A consistent supplier name. Different spellings are not merged automatically. |
| invoice_reference | The invoice the allocation settled. |
| payment_id | The actual transaction reference. Essential for distinguishing two payments from two export rows. |
| date | Payment date, YYYY-MM-DD. |
| amount | The settled allocation, in major units such as 1234.56. |
| currency | USD, EUR, GBP, CAD, AUD or NZD. No automatic conversion. |
| status | paid, settled, cleared, completed, reversal, or an explicit void/unpaid status. |
| invoice_total | Optional original full invoice obligation, including tax and adjustments. A partial amount is not a valid total. |
Supplier credits and your ledger
Both files use entity, vendor, credit_reference, date, open_amount and currency. Use a positive remaining balance in open_amount. Do not upload several monthly snapshots of the same credit. A fully applied credit has no open balance.
Before running the scan
- Use the same cutoff date and consistent entity/vendor names.
- Remove subtotals and report footers.
- Export UTF-8 comma-separated CSV. Use dot decimals and ISO dates.
- Represent reversals as negative amounts with status reversal.
- Include all allocations within the invoice scope, so an apparent overpayment is not a partial picture.
When your source uses different column names, map the columns in the workspace. CreditLatch does not guess missing payment evidence or silently skip malformed amounts.