Topic

Working Out What Someone Paid When All You See Is a Balance

β€’ 7 min read
Article preview

The money is collected by a platform we do not run. We never see the payments. What arrives is a single figure, now and then: what is currently owed. Last month it was 2,400 and today it is 2,150, so something has moved it by 250, and we have to decide what that means before we can say whether any instalment has been paid. Then the balance goes up, and that is where most approaches quietly go wrong. A rise is not a payment, but it is also not nothing. It might be interest, a fee, a correction, or a payment that has been reversed, and each of those needs handling differently. Treat them all the same and a customer who paid on time can have their paid instalments silently undone by an interest charge. This paper sets out how to decide what a balance movement actually was before doing anything with it. The rule is that the system checks for a record explaining the movement, and where there is no record it says so and stops rather than guessing. It then defines how to spread a genuine payment across instalments, how to unwind one properly when a payment is reversed, and what must always remain true throughout so that nobody ends up over-credited or wrongly un-credited. It also says plainly where this stops working. The approach depends on being told about interest, fees, and reversals. Where that information is missing it does not quietly approximate. It raises its hand and asks for help, which is the intended behaviour rather than a shortcoming.

Technical reconciliation incomplete information data quality payment allocation

Computing Obligation Satisfaction from Balance Snapshots

The problem

A customer owes GBP 2,400, repayable over twelve monthly instalments of GBP 200. The money is collected by a servicing platform we do not own. We receive no payment transactions. What arrives, on an irregular schedule, is a single figure: the outstanding balance as observed at a point in time.

Last month it was 2,400. Today it is 2,150. Something reduced it by 250.

We have to decide what that 250 means. If it is a payment, some part of it satisfies instalment one and the remainder starts on instalment two. If it is a correction to an over-stated opening balance, none of it satisfies anything. We cannot ask. The number arrives without provenance and we have to allocate it deterministically, because two systems reading the same snapshot must reach the same allocation or the obligation has no agreed condition at all.

Then next month the balance goes up.

That is the harder half of the problem and the reason this paper exists. A rising balance is not evidence of payment, and a reconciliation model that only handles falling balances will eventually meet a rising one and do something incorrect with it. The specific defect we are naming is the interpretation of unclassified balance movement as payment evidence. Its consequence is that a customer's satisfied instalments can be silently un-satisfied by an interest posting.

This paper defines how balance movement is classified before it is allocated, how allocation and reverse allocation preserve financial invariants, and under what conditions the computed satisfaction state converges on the true one. It does not decide whether the arrangement is broken. That belongs to the state machine defined in the companion paper, Repayment Arrangements as Deterministic State Machines, for which this model is the allocation source.

What this model consumes and produces

Inputs

Input Description Availability
Instalment schedule Amount and due date per instalment At creation, immutable
Balance snapshot Outstanding balance with observation timestamp Irregular, may be delayed or missing
Adjustment record Structured notification of interest, fee, correction, or reversal, with type, amount, and effective date Optional, and its absence is itself significant
Payment event Discrete payment with amount and identifier, where the integration supplies them Optional
Staleness threshold Days after which snapshots are considered stale Configuration

Outputs

Output Description
Allocation state Absolute per instalment
Classification record For each observed delta: its value, classification, and the record that justified it
Reversal marker Assertion that an allocation update decreased a value, with justification
Staleness declaration Assertion that no reliable allocation has been derived since a given time
Diagnostic flags Named unresolvable conditions

Explicit non-inputs

  • Transaction history. We cannot reconstruct the sequence of payments behind a balance.
  • Payment provenance. We do not know whether a reduction came from the customer, a third party, or an internal correction, except where an adjustment record says so.
  • Arrears ageing below schedule level.
  • Arrangement state. This model does not read the state machine's output, which keeps the dependency one directional.

Non-goals

The model does not decide arrangement state, does not calculate interest or fees, does not select a collections action, and does not resolve flagged anomalies. It answers one question: given the observations received, how much of each instalment is satisfied, and how confident can the system be in that answer?

Bounding assumptions

  • Snapshots are accepted in observation time order. Out of order snapshots are rejected, not reordered.
  • Interest and fees are computed externally and reach the model only as balance movement, ideally with a record.
  • Allocation order is due date ascending. Where contractual or regulatory allocation order differs, the algorithm must be replaced and the convergence property re-derived.

Classifying before allocating

The movement between two accepted snapshots is:

Positive means the balance fell. Negative means it rose. Only the first is potentially evidence of payment, and the discipline of this model is that even the first is not allocated until classified.

Earlier formulations of this idea classified negative movement by attribution to fees, interest, or reversal without specifying how attribution is determined. That leaves classification to a someone reading the account, which removes determinism at exactly the point the model claims to supply it. We classify against records, and where no record exists we say so rather than guessing.

Condition Classification
payment
neutral
, matching adjustment record of type interest, fee, or correction exogenousAdjustment
, matching reversal record reversal
, no matching record, or records do not reconcile exactly anomaly

Matching is defined strictly. The record's effective date falls in the interval and the sum of record amounts in that interval equals exactly. A partial match is an anomaly, not a partial application. Tolerance thresholds reintroduce the interpretation problem the classification function exists to remove, and any tolerance value would itself be an operator judgement.

Reversal is never inferred from sign. It requires an explicit record. This is the difference between a model that occasionally un-pays a customer by accident and one that cannot.

Where discrete payment events are available they are classified as payment by construction, since provenance is known, and allocated identically. The two input paths converge immediately after classification.

Allocating

Positive movement

For instalments in due date ascending order:

Repeat until or no unpaid instalment remains. Residual delta after full allocation is recorded as surplus and flagged. It never produces negative .

Allocation proceeds through instalments not yet due once earlier ones are satisfied. Advance allocation is a legitimate outcome, not an error, and the companion state machine represents it.

Exogenous adjustment

The balance takes its observed value and no instalment changes. Interest and fees increase what is owed. They do not invalidate instalments the customer has already paid. This one line is the practical payload of the classification function.

Reversal

Let . For instalments in reverse allocation order, most recently allocated first:

Continue until or no allocated instalment remains. Residual is flagged, never absorbed. Every instalment whose decreases is emitted with a reversal marker, because the consuming state machine rejects unmarked regression.

Anomaly

The balance is updated to the observed value, since the observation is real. No allocation changes. The condition is recorded:

The flag persists until a later record reconciles it or an operator resolves it. Unverified balance movement never rewrites satisfaction.

What must always hold

Net conservation.

The adjustment term is required because exogenous growth otherwise breaks the identity on the first interest posting. The reversal term is required because a reversed payment left in the payment sum breaks it on the first reversal. Payments are counted net.

Allocation integrity. . Reverse allocation preserves the lower bound because cannot drive below zero. Forward allocation preserves the upper bound because cannot exceed the shortfall.

Non-destructive reconciliation.

Negative movement invalidates established allocation only when classified as a reversal against a record. This is the most important safety property in the model and the one most likely to be quietly weakened during implementation, usually by someone adding a tolerance to make the anomaly count fall.

Classification precedes application. No balance movement updates allocation before is determined and recorded. There is no default path.

Anomalies are inert. An anomaly changes the balance and the flag set. It changes nothing else. Every other invariant therefore holds trivially under anomaly, which is precisely why anomaly is the safe default for unclassifiable movement.

Why this converges, and when it does not

Let be the allocation state at time and the true satisfaction state of the obligation. The model evolves under:

Determinism requires that the same observation against the same state yields the same result, and that duplicates are absorbed:

This holds for snapshots naturally, because a repeated snapshot yields and classifies as neutral. For discrete payment events it requires deduplication on identifier before the event reaches the function.

Convergence is defined separately over confirmatory and adverse observations. Let be observations consistent with satisfaction and adverse ones:

is allocative and convergence promoting.

is classificatory, balance adjusting, or reconciliation triggering. Then:

provided that observations are eventually consistent, that adverse deltas are correctly classified, and that the invariants hold.

The middle condition is not free. It depends entirely on an adjustment record feed we do not control. Where that feed is incomplete, deltas classify as anomaly, allocation stops advancing, and the model does not converge. It accumulates flags instead.

We regard that as the correct failure behaviour rather than a defect, because the alternative is a model that continues to produce confident allocation while drifting from the truth. But it should be stated plainly: this model converges when it is fed, and announces itself when it is not. It does not degrade gracefully into approximation, by design.

Where it is probed

A snapshot arrives out of order. The day 30 snapshot arrives after the day 35 snapshot. Computing a delta against the wrong baseline manufactures a spurious negative. Rule: accept a snapshot only where its observation timestamp exceeds that of the last accepted snapshot. Reject and flag OutOfOrderSnapshot. Do not reorder, because reordering requires reprocessing already emitted allocation.

No snapshot arrives for longer than . Rule: emit a staleness declaration. The consuming state machine suspends monitoring on receipt. Allocation state is unchanged, not zeroed. This exists because elapsed silence is not evidence of non payment, and a model that lets an arrangement fail on missing snapshots has converted an integration outage into a customer outcome.

Balance reaches zero with instalments unsatisfied. Early settlement, external write off, or a wrong snapshot, and we cannot distinguish them from a balance. Rule: allocate the full delta in due date order, then flag UnexplainedSettlement if instalments remain unsatisfied. Do not fabricate allocation to force the schedule to reconcile.

Delta exceeds total outstanding across the schedule. Rule: allocate across all unpaid instalments, record the residual as surplus, flag SurplusUnallocated. Never allow .

Reversal exceeds total allocated. Reverse allocation exhausts every allocated instalment with remaining. Rule: flag OverReversal, do not create negative allocation. A reversal larger than everything ever allocated is a data quality condition, not a financial one.

Adjustment record arrives after the snapshot it explains. A negative delta classified as anomaly at , and the interest record arrives at . Rule: reclassify the historical delta, apply the correct handling, clear the flag, and retain both the original classification and the correction in the record. This is the only retrospective operation the model permits, and it is bounded: it may not be applied where the consuming arrangement has reached a terminal state. Such a record is flagged PostTerminalReclassification and has no effect. A model that can revise inputs to a terminated obligation makes termination meaningless and the convergence argument collapses with it.

Two adjustment records in one observation window, only one matching. Records for 40 and 60 against a delta of 40. Rule: matching is on the exact sum across the window, so this does not match and classifies as anomaly. Selecting the convenient record would be interpretation, and interpretation is what the classification function exists to eliminate.

Balance rises with a matching record while an anomaly flag is already open. Rule: classify and apply the new movement normally. Open flags do not block subsequent processing, because blocking would let one unexplained delta freeze an account indefinitely.

The artefact

A five value classification function with record based attribution, forward and reverse allocation algorithms, five invariants, a staleness declaration protocol, and a bounded reclassification rule.

When to use it

  • Obligation satisfaction must be computed from balance observations rather than transactions.
  • The balance can rise as well as fall, from sources outside the payment stream.
  • Some form of adjustment or reversal record exists, even if imperfect.
  • Two systems must agree on allocation without agreeing on interpretation.

When not to use it

  • You have a complete, ordered, reliable transaction stream. A ledger is simpler and correct, and this model adds classification machinery for a problem you do not have.
  • No adjustment records exist in any form. Every negative delta becomes an anomaly and the model degrades into a flagging system rather than a reconciliation one. That may still be worth deploying, but it should be chosen knowingly.
  • Allocation order is contractually mandated in a way that conflicts with due date ascending. The algorithm must be replaced and convergence re-derived against the replacement, which is real work rather than a configuration change.
  • Approximate reconciliation is acceptable and flag volume is not. This model is strict on purpose and will generate anomalies where a tolerant model would generate silence.

Constraints on use

  • Requires as configuration. Leaving staleness to judgement removes the protection the staleness declaration provides.
  • Requires adjustment records with effective dating and exact amounts. Tolerance is not a tuning parameter here, it is a removal of the determinism guarantee.
  • Requires deduplication of discrete payment events on identifier upstream.
  • Requires that the consumer of allocation output honours reversal markers and staleness declarations. Emitting them to a consumer that ignores them provides no protection.
  • Assumes interest and fees are computed externally. The model interprets movement, it does not calculate it.

What this leaves open

Convergence is conditional on a feed we do not own, and we have no mechanism for detecting a systematically incomplete adjustment feed as distinct from an account with genuinely unexplainable movement. Both present as accumulating anomaly flags. Distinguishing feed quality from account pathology probably requires a population level view that sits above this model, and we have not defined it.

The strictness of exact matching is a position rather than a proof. We have argued that any tolerance value would be an operator judgement and therefore a determinism failure, and we still think that is right. But we have not tested it against a portfolio where rounding differences are endemic, and it is possible that the correct answer is a tolerance that is itself derived from a stated rule rather than chosen. We do not currently have that rule.