Payments
Record a payment, allocate it across the invoices it settles. Outstanding AR on the dashboard updates the moment you save.
Seven payment modes covered.
The same set every Indian SMB actually uses. Enforced at the DB with a CHECK constraint — no typos in your books.
Partial allocation: one payment, many invoices.
A customer wires ₹50,000 to settle three open invoices of
₹20,000, ₹15,000, and ₹15,000. mb stores the payment once, and
the payment_allocations table records three rows —
one per invoice — with the allocated amount on each.
The sum of allocations cannot exceed the payment's amount
(validated server-side). Each affected invoice's balance updates
as total − sum(allocated) — the same formula the AR
aging report and the outstanding-AR KPI use.
| Invoice | Total | Allocated | Balance |
|---|---|---|---|
| INV/26-27/0021 | ₹20,000.00 | ₹20,000.00 | ₹0.00 |
| INV/26-27/0022 | ₹15,000.00 | ₹15,000.00 | ₹0.00 |
| INV/26-27/0023 | ₹15,000.00 | ₹15,000.00 | ₹0.00 |
| Payment | ₹50,000.00 | ₹50,000.00 |
Idempotency-Key on every mutation.
POST /payments (and /invoices,
/suppliers, /purchases) honour the
Idempotency-Key request header. Send a UUID with
the request; if the network drops mid-flight and you retry with
the same key, mb replays the cached response instead of
double-recording.
Keys expire after 24 hours via a janitor goroutine. Stuck
processing rows are reclaimed after 5 minutes so a
crashed original request doesn't lock a key forever.