Credit Notes & Client Billing
Apply customer credits against invoices with a per-invoice audit trail, and give every client a monthly statement whose closing balance actually adds up.
The problem
A customer is owed $500 from a botched project. Someone notes it in QuickBooks, then applies it by adjusting the invoice by hand. Two weeks later the customer pays the balance by card, the payment sync recalculates what the invoice has received, and the manual adjustment vanishes — so the customer is chased for money they were already credited. Nobody notices until they call.
Underneath that is a smaller, worse problem: when finance asks which invoices a credit was spread across, and who authorised it, the answer is somebody’s memory. And the monthly statement the client receives shows charges and payments but no balance, so there is nothing to reconcile it against.
What Solidlio does about it
An invoice’s paid amount is derived, never adjusted: it is the sum of settled payments net of refunds, plus every un-reversed credit-note application. Because both are terms in one calculation, a credit and a payment cannot overwrite each other, and recomputing is safe to repeat. Each application of a credit writes its own ledger row — amount, target invoice, who applied it, when — so a credit split across three invoices leaves three traceable lines rather than one guess. Applications are reversed, never deleted, and the database refuses to destroy the history. Statements are built on the same figures, so each month’s closing balance is an identity you can check rather than a number you have to trust.
Capabilities
| Capability | What it does |
|---|---|
| Credit application | Applies part or all of a credit note to an invoice, refusing over-application on either side |
| Split credits | Spreads one credit across several invoices, recording each draw separately |
| Application ledger | Records amount, target invoice, actor and timestamp for every draw |
| Reversal | Returns credit to the note and balance to the invoice; marks the row reversed, never deletes it |
| Currency safety | Refuses to apply a credit to an invoice in a different currency instead of converting at 1:1 |
| Concurrency safety | Locks both rows before reading, so two simultaneous applications cannot double-spend one credit |
| Reconciling statements | Monthly opening / charges / payments / credits / closing, chained across the whole period |
| Transaction history | Invoices, payments and credit notes in one feed with exact totals |
| Client credit lines | Records each client’s credit limit, net terms, payment-history rating and status |
| Escalation billing | Turns completed escalation work into a platform fee and a service order, once, on demand |
Built for MSPs and their clients
A managed client is a separate account, not a folder inside the MSP’s. Solidlio keeps two scopes apart on purpose: an MSP is widened to the money of every client it services, but never to another MSP’s commercial terms.
| Organization | MSP | |
|---|---|---|
| Credit notes | Reads its own credits and their full application history | Applies and reverses them — writing off a receivable is the MSP’s decision |
| Invoice balance | Sees the effect on what it owes | Sees the same figure, derived identically |
| Credit line | Sees its own limit, terms and utilisation | Sets the limit, terms and status |
| Statements | Reads its own reconciling monthly series | Reads it for every client it services |
| Auto-pay | Turns it on, picks the method, caps the amount | Does not control it |
Credit lines stay scoped to the providing MSP: a second, co-managing MSP on the same client sees that client’s invoices and credits, but not the terms the primary MSP negotiated.
How it works
- A credit arrives. Credit memos sync from QuickBooks into Solidlio as credit notes, carrying their real currency and remaining balance.
- Staff apply it. An MSP technician applies an amount to an invoice in the same currency. Both rows are locked before they are read, so two people cannot spend the same credit twice.
- A ledger row is written. Amount, invoice, person and timestamp. A partial application leaves the note live with the remainder available for a different invoice.
- The invoice balance is recalculated, not adjusted — payments net of refunds, plus un-reversed credit applications. A later card payment or refund recomputes the same total and cannot erase the credit.
- A mistake is reversed, not erased. The credit goes back on the note, the invoice balance is restored, and the reversed row stays on the record with who reversed it.
- The statement reflects it. The month’s
creditsfigure moves, and the closing balance follows the identityopening + charges − payments − credits.
Compliance and audit
What can be reconstructed after the fact, from stored records rather than logs:
- Every credit application, individually: amount, target invoice, the person who applied it, and the timestamp — including applications that were later reversed, with who reversed them and when.
- The database refuses destruction. Foreign keys on the application ledger are
RESTRICT, so a credit note with history cannot be deleted. There is no destructive path for a credit application anywhere in the API. - Terminal invoice states are protected. A cancelled (
VOID) or unissued (DRAFT) invoice is never re-issued by payment or credit activity — a defect that used to silently revive voided invoices on a refund. - Money arithmetic is exact. Amounts move through fixed-point decimal, never floating point, end to end.
- Statements are checkable. Each month’s closing balance is a stated identity over its own inputs, and the oldest month’s opening balance is computed from everything before the window rather than assumed to be zero.
The paid-amount calculation is implemented twice — once in the payments service, once in billing — because services cannot import each other’s internals. A differential test pins the two implementations against each other across nine scenarios including partial refunds, over-refunds and reversed credits. It caught a genuine disagreement between them on its first run.
Editions
Included in every plan, including Free. Credit notes, credit lines, statements, transaction history and escalation billing carry no plan gate. The only money-related plan limit in Solidlio is the contract cap, which belongs to Contracts.
Integrations
- QuickBooks Online — credit memos sync into Solidlio as credit notes, carrying their currency and remaining balance, and reconcile on re-sync. This is currently the origin of every credit note in the system.
- Stripe — card and pre-authorised debit payments feed the same derived invoice balance that credit applications feed, so the two settle one figure rather than competing for it.
Credits are money. Solidlio treats them like money — recorded once, applied traceably, and impossible to quietly delete.