From scattered payment evidence to an approved batch.

1. Bring the records together

Receipts need reference, date, payer, amount and currency. Invoices need invoice number, customer ID/name, current open amount and currency; issue/due dates are optional. Select each file’s date convention explicitly: YYYY-MM-DD, MM/DD/YYYY or DD/MM/YYYY; one- or two-digit slash dates are accepted only under that chosen convention and normalized to ISO dates. Impossible calendar dates are rejected. Optional remittance CSV needs payment reference, payer, customer ID, invoice reference, advised amount and currency. Map the currency column for files containing per-row or mixed currencies. If no currency column is mapped, explicitly confirm one supported currency for every row in that file. A blank or invalid mapped currency cell is still rejected; the file choice never fills it.

Use one record per row, a consistent selected date convention, positive decimal amounts with at most two decimal places, and explicit USD, AUD, CAD, EUR, GBP or NZD. Maximum 5 MB and 10,000 rows per file. Check the first five normalized source rows before importing; invalid rows remain visible and block the whole file. Up to 20 file/row/field errors are shown with the total problem count. No rows are silently skipped. CSVs with parser errors or duplicate identities must be corrected first. Matching is unavailable while a file is loading; failed or cancelled reads preserve your prior selection. Installing a different file requires fresh confirmation that the records belong to one legal entity.

Use prior applications to reduce payer questions

After importing current records, optionally add an application-history CSV from the same business. Use application_id, payment_id, payment_date, payer, customer_id, invoice_id, applied_amount, currency and status columns; dates must be YYYY-MM-DD and status applied or reversed. Use positive applied amounts even for a row marked reversed. Maximum 5 MB / 10,000 application rows. The template is a fallback format, not a native accounting export preset.

The prototype proposes a customer relationship only when at least two distinct earlier payments consistently support it. Multiple invoice lines from one payment count as one payment. Conflicting payers/customers, currencies, reversed history and current-or-later records do not become trusted context. Inspect the source application IDs, confirm the selected relationships together, then review the remaining payer questions. Past bookkeeping is supporting evidence, not guaranteed correctness or a measured accuracy score.

History is optional and stays in this tab. Keep the original file: historical rows are not included in the existing encrypted batch checkpoint. The separate history readiness report is an unencrypted download containing the imported history and proposed relationships, not an approval receipt. Customer-authorised accounting and US bank connections are planned, not live in this release; bank movements alone do not explain invoice allocation.

2. Confirm who paid

A treasury company or DBA can differ from the invoice customer. Select and confirm the customer from real evidence. That relationship is retained only for this batch. Changing source/customer evidence clears approvals and recovered drafts so they can be reviewed again.

3. Review a proposal—or explain the exception

Exact references and structured advice produce transparent allocation lines. Partial payments leave invoice balances open. Equal amounts without adequate evidence remain ambiguous. Use manual allocation only with a review reason and within remaining balances. A deduction claim is not an approved write-off.

If advice is missing, check whether your bank offers the underlying ACH addenda/remittance report, then use the local remittance-request draft to ask the payer for invoice-level details. The app does not send email or access your mailbox.

4. Close the cash-allocation batch

Approve every receipt or explicitly leave it unapplied. Open the batch handoff to review separate currency controls, decisions and invoice balances projected from your imported open amounts. Choose individual downloads: allocations, unapplied cash, invoice balances, a readable decision report and source-bound audit JSON. These handoff downloads are not encrypted. Check that each requested file was saved on your device. Record reviewed results in your accounting system without creating a second cash receipt if one already exists. Nothing is automatically posted.

Pause and resume a private review

In your authenticated workspace, choose Save encrypted checkpoint before leaving the tab. It preserves source rows, payer mappings, decisions and recovered drafts—not unsaved form notes. Choose a long unique passphrase of at least 16 characters (maximum 256 UTF-8 bytes), confirm it, and check that the encrypted file downloaded. Keep the passphrase separately: we cannot recover it or delete your downloaded files. There is no automatic or cloud backup.

To continue, sign in to the same active Remit account and choose Restore checkpoint. Decrypt locally, inspect the preview and explicitly confirm replacement of the current batch. Saved decisions return as drafts, never approvals. Confirm each payer again, verify that imported balances are still current, then individually approve or correct recovered work. Ordinary exports exclude unapproved drafts. This recovery option is separate from the public synthetic example.

Not supported in this release

PDF/OCR/AI extraction, bank feeds, mailbox ingestion, ERP posting, full bank/AP reconciliation, credits, write-offs, payment reversals, net processor settlements and cross-entity/FX transactions are not implemented. Do not reshape those records into ordinary positive receipts just to pass validation.