Receipts & Settlement
The problem
Payments arrive by transfer, in cash, in parts, and out of order. The risk is not arithmetic; it is recording the same payment twice because a page was refreshed, or issuing a receipt nobody can later tie to an invoice.
How Mersal solves it
Settlement records partial or full payments against an invoice, validated so the ledger cannot be overfilled, and protected by an idempotency key so a retry or a second tab cannot double-record. A receipt issues on its own serial, is generated as a document, and is emailed to the client.
How it works
A retry is not a second payment
Each settlement carries a client-generated key. If the response is lost and the request repeats, the second attempt resolves to the same receipt rather than a second one.
Its own serial, sealed
Receipts number independently of invoices and, once issued, are protected against amendment or deletion by firm members.
Partial payments stay legible
A part payment records what was received and what remains, so the outstanding balance is a fact rather than a subtraction someone did in their head.
What it prevents
- Double-recording a payment after a network retry
- A receipt that cannot be tied to an invoice
- Quietly amending a receipt after the fact
The fastest way to judge this is to watch it run against your own way of working.