← Back to blog

Corrective Adjustments: Signed Money Corrections With Maker/Checker Built In

Goodwill credits, SLA breach refunds, rate corrections, opening balances, and dispute settlements — Finno’s adjustments move consumer and provider money with two operators, never one.

Finno corrective adjustments — a proposed credit awaiting a second operator’s approval before money moves.

Ordinary metering covers the happy path: reserve, serve, finalize, account.

Real platforms also need exceptions. A goodwill credit after an outage. An SLA breach refund. A mispriced rate discovered after the invoice. An opening balance when a customer migrates in. The money leg of a settled billing dispute.

Those are not “manual journal hacks.” They are first-class financial events — and they need the same discipline as everything else Finno touches.

Corrective adjustments are signed corrections to what a consumer owes, or what Finno owes a provider, for the cases metering cannot express.

Two tables, on purpose

Consumer money and provider money live in different places. So do their adjustments.

ConsumerProvider
What changesWallet / receivable in the replicated ledgerAccruals netted into the next settlement
After approvalGateway leader reconciles a pending fact into RaftJournal posts immediately; cash waits for settlement
Sign conventionPositive credits them (they owe less)Positive means we owe them more

Both signs are in favour of the counterparty. That framing is deliberate: one resolved dispute often writes a row in each table — credit the consumer, claw back from the provider — and “in favour of the counterparty” is the only wording that reads correctly for both at once.

Maker / checker on every amount

Every adjustment is proposed by one operator and approved by a different one. Self-approval is refused. There is deliberately no value threshold below which approval is skipped.

A threshold is one more thing to misconfigure. The second click is cheap. “Small enough to self-approve” is precisely the shape a bad actor aims for.

Statuses move pending → approved (and for providers, later settled), or rejected with a reason that moves nothing.

Reason codes are fixed sets — goodwill, sla_credit, dispute, rate_correction, penalty, opening, correction, and siblings — so a bad value is a clear 400, not a constraint-violation 500.

What operators see

Admin → Adjustments has three tabs: Consumer, Provider, and Uncollectible.

The workflow is short:

  1. Propose — party, signed amount, reason code, and free-text why (what the second operator and next year’s auditor will read). Optionally attach an invoice, dispute, or settlement subject.
  2. Approve — a different operator. The panel says you cannot approve your own before the server refuses you.
  3. Watch it land — consumer rows distinguish approved from applied. Only applied money has moved through the ledger. If something stays approved-not-applied for minutes, check the gateway leader’s reconcile loop — not the adjustments form.

A consumer adjustment may carry tax alongside gross so a credit note can reverse VAT the way the original invoice charged it. Leave tax empty for pure goodwill that was never taxed.

Provider claw-backs and the uncollectible tab

Debiting a consumer always lands (wallet first, then receivable).

Debiting a provider may not. A provider has no wallet; a claw-back only executes if they have future earnings to net against. An overpaid provider who has been settled and never works again leaves a negative row that sits unsettled — a collections problem Finno surfaces rather than swallows.

The Uncollectible tab and a standing anomaly detector watch aged provider claw-backs with nothing left to net against, so finance is not surprised by a silent hole in the books.

Not the ledger-correction button

Finno also has a narrow admin tool for repairing a trial-balance imbalance left by a past bug. That tool moves no balance and never reaches Raft.

Adjustments are the opposite: they are how money intentionally moves when metering is not the right story. The names are close enough to be a hazard — use the adjustments module when you mean to change what someone owes.

What this unlocks

  • Finance-ops corrections without spreadsheet side channels
  • Dispute outcomes that settle into the same tables as day-to-day credits
  • Audit trails with two names on every movement
  • Provider settlement that nets approved adjustments instead of ignoring them

What to ask your team

When someone needs a credit today, who can approve their own entry — and where does that money actually land?

Explore Finno’s finance operations or contact us for a walkthrough.