Arrears Delta Apportionment is a deterministic model that allocates inferred net reductions in total due across instalments when only balance snapshots are available.

It replaces transaction reconstruction with controlled state convergence based solely on balance deltas.

This model is designed for integrations where the only available signal is a periodic arrears balance snapshot. Because no transaction level data is available, the system does not attempt to reconstruct payments. Instead, it allocates inferred net reduction in total due between trusted snapshots.

Allocation is performed incrementally using:

a strict baseline
a delta calculation
an offset against accumulated adverse movement
a sequential waterfall across instalments

Negative balance movement does not reverse prior allocations. It is recorded explicitly as state, and it is extinguished by subsequent positive movement before any allocation occurs.

Overpayments, missed status, and next payable logic are derived consistently from the same temporal reference. Metadata is persisted to ensure idempotency, replay safety, and auditability.

The result is a constraint driven, state convergent allocation approach that remains deterministic even when signals are incomplete, delayed, or partially missing.

Problem

In some collections integrations, the only available input from the host banking system is a periodic arrears balance snapshot.

In this environment I cannot observe:

payment transactions
posting order
reversals
fee application

Yet I am still required to allocate value across an instalment schedule deterministically.

This model addresses that constraint.

Instead of reconstructing payment history, the system converges on the only signal that can be trusted:

Balance movement between two known points in time.

Explicit Limitations of Arrears-Only Integrations

In an arrears-only integration I receive exactly two fields:

currentBalance, being the total arrears balance
balanceProcessedDate

I do not receive payment events.

The earlier version of this model described the input as total arrears balance or outstanding balance. That is a defect rather than flexibility. Arrears and outstanding balance are different figures on most host systems, and two implementations choosing differently produce different deltas from the same file. The field is arrears. Where a host supplies only outstanding balance, that is a different integration and this model must be re-derived against it.

When the balance decreases between two trusted snapshots, I infer that net value has been applied to the account.

However, that value is not a known payment.

If arrears moves from:

£1,000 to £850

I cannot determine:

whether a single £150 payment occurred
whether multiple payments occurred
whether fees offset payments
whether reversals occurred

All I can prove is:

Total due reduced by £150 relative to the prior trusted state.

Therefore what I allocate is not a payment event.

It is net arrears reduction.

Terminology: Arrears Delta Apportionment

The name makes three structural realities explicit.

1. Arrears

The signal is total due, not transactional cash flow.

2. Delta

The allocatable value is the difference between two balances, not a payment instruction.

3. Apportionment

That delta is deterministically allocated across obligations according to defined rules.

When arrears decrease, value becomes eligible for allocation through a strict waterfall, after any accumulated adverse movement has been offset.

When arrears increase, the system does not reverse prior allocations. The increase is recorded as explicit state.

Therefore the model does not apportion payments. It performs deterministic allocation of inferred net arrears reduction across a contractual schedule.

System Constraints

The system operates under the following non-negotiable constraints.

The only reliable fact is that balance moved between two trusted snapshots.
All decisions must be evaluated relative to balanceProcessedDate, not system clock time.
Previously applied allocation must not be implicitly reversed based on balance increase alone.
The system must tolerate duplicate file delivery and reprocessing without adverse effect.
Every run must persist enough metadata to reconstruct allocation deterministically.
Accumulated adverse movement must be extinguished before positive movement reaches the waterfall.

The sixth constraint is new. Its absence was the most significant defect in the earlier version and is explained in the negative delta section below.

These constraints shape the entire model.

Reframing the Problem as State Convergence

Because transaction data is unavailable, the system cannot answer:

What payments happened?

Instead it asks a provable question:

How much has the balance moved since the last trusted state?

This reframes the system from transaction reconstruction to state convergence.

Only balance deltas are admissible inputs.

Everything else becomes derived state.

State Model

Before defining transitions, the state must be explicit.

Arrangement-Level State

arrangementCreatedDate
balanceAtArrangementCreation
lastApportionedBalance
lastBalanceProcessedDate
unappliedNegativeDelta
overpaidAmount

lastBalanceProcessedDate is new. The earlier version enforced chronological processing against a field called lastProcessedDate that appeared nowhere in the state model or the persisted metadata, so the rule could not actually be implemented as written.

Instalment-Level State

sequenceNumber
dueDate
scheduledAmount
unpaidAmount
paidAmount
state
nextUnpaid

The earlier version carried isMissed as a boolean. A boolean is a flag, not a state, and it cannot express the difference between an instalment that is not yet due and one that is due but within its window. Instalment condition is now a named state derived deterministically from allocation and date.

Instalment States

State	Condition
`Pending`	`dueDate > balanceProcessedDate` and `paidAmount = 0`
`PartiallyPaid`	`dueDate > balanceProcessedDate` and `0 < paidAmount < scheduledAmount`
`Due`	`dueDate <= balanceProcessedDate` and `unpaidAmount > tolerance` and grace window not elapsed
`Missed`	`dueDate + graceDays <= balanceProcessedDate` and `unpaidAmount > tolerance`
`Paid`	`unpaidAmount <= tolerance`

These are mutually exclusive and cover every combination of date and allocation. Paid is evaluated first and takes precedence, so a fully allocated instalment is never Missed regardless of date.

graceDays is a required configuration value. The earlier version moved an instalment to missed the moment its due date passed with any unpaid amount, which meant an instalment due on the snapshot date was reported as missed on that same date. That is a determinism problem only in the sense that it is deterministically wrong: it produces a missed status before the customer has had the day the schedule gives them. Setting graceDays = 0 reproduces the original behaviour where that is what a client actually wants.

Tolerance

A configurable tolerance defines what counts as effectively zero unpaid.

Tolerance applies in three places and the earlier version defined only the first:

unpaidAmount <= tolerance counts as fully paid.
abs(delta) <= tolerance counts as no movement and exits without mutation.
unappliedNegativeDelta <= tolerance counts as extinguished and is zeroed.

Without the second rule, sub-penny rounding drift in the host balance produces a delta every run, each of which allocates a fraction and advances the baseline, and the schedule slowly desynchronises from the balance.

State Invariants

These invariants must always hold.

paidAmount + unpaidAmount = scheduledAmount for every instalment
Exactly one instalment has nextUnpaid = true, or none where all are Paid
paidAmount cannot decrease through delta processing
Negative delta does not mutate instalment state
Allocation order is strictly ascending sequenceNumber
unappliedNegativeDelta >= 0 and overpaidAmount >= 0
Conservation: balanceAtArrangementCreation - currentBalance = sum(paidAmount) + overpaidAmount - unappliedNegativeDelta

Invariant 7 is new and is the one that catches the defect described below. The earlier model had no invariant tying allocation back to observed balance movement, which is why an inconsistency between the two could accumulate without any check failing.

Invariant 2 previously read that only one instalment may have nextUnpaid = true. That admits zero, which is correct only when the schedule is fully paid. Stated as it was, an implementation with no next instalment on a live schedule violated nothing.

Allocation Lifecycle

Step 1. Validate Snapshot

Reject and exit without mutation where any of the following hold:

balanceProcessedDate < arrangementCreatedDate
balanceProcessedDate < lastBalanceProcessedDate
currentBalance is null or negative

Host state must not back-propagate into a schedule that did not exist, and older snapshots must not distort the baseline.

Where balanceProcessedDate = lastBalanceProcessedDate and currentBalance differs from lastApportionedBalance, the host has restated a snapshot already processed. Reject and flag for reconciliation. The earlier version did not consider this case: it passed the chronological check and was then processed as a normal delta against a baseline that already incorporated the same date, which silently double counts.

Step 2. Determine Baseline

If this is the first run:

baseline = balanceAtArrangementCreation

Otherwise:

baseline = lastApportionedBalance

Step 3. Compute Delta

delta = baseline - currentBalance

Delta represents net arrears movement since the last trusted state.

If abs(delta) <= tolerance, exit without mutation and advance lastBalanceProcessedDate only.

The system never recomputes from scratch. It applies incremental movement since last convergence.

Step 4. Offset Accumulated Adverse Movement

This step is new and sits between delta computation and allocation.

Where delta > 0 and unappliedNegativeDelta > 0:

offset = min(delta, unappliedNegativeDelta)
delta = delta - offset
unappliedNegativeDelta = unappliedNegativeDelta - offset

Only the remainder proceeds to the waterfall.

Why this is required. The earlier version accumulated adverse movement and never resolved it. Consider a £20 fee applied to an account, followed by a payment that clears the balance entirely. The fee is recorded as unappliedNegativeDelta = 20. The subsequent positive delta includes the £20 the customer paid to cover that fee, and with no offset step the model allocates it to the schedule, finds the schedule already satisfied, and books £20 as an overpayment.

The account then simultaneously reports £20 of unresolved adverse movement and £20 of overpayment, which are the same £20 counted twice in opposite directions. The customer has not overpaid. They have paid a fee. The offset step makes the model report that correctly, and invariant 7 now fails if an implementation omits it.

The earlier version's own structural validation questions asked what process resolves unappliedNegativeDelta. The honest answer at the time was none.

Positive Delta Allocation

If, after offset:

delta > 0

The balance decreased by more than any adverse movement outstanding.

This is interpreted as net value available for allocation.

remaining = delta

For instalments in ascending sequenceNumber:

allocate = min(remaining, unpaidAmount)

paidAmount += allocate
unpaidAmount -= allocate
remaining -= allocate

If after all instalments:

remaining > 0

Then:

overpaidAmount += remaining

The waterfall is strict:

no skipping
no reordering
no retroactive adjustment

Given identical state and delta, allocation is identical.

overpaidAmount is terminal within this model. It is not allocated to future instalments and is not refunded here. It is surfaced as state for a process outside this model to resolve, and that process is not defined by this artefact.

Negative Delta Handling

If:

delta < 0

The balance increased.

This could represent:

fee application
reversal
correction

The signal does not identify which.

Therefore the system does not infer.

Instead:

unappliedNegativeDelta += abs(delta)

Instalment state remains unchanged. Previously applied allocation is never implicitly undone.

The accumulated figure is not permanent. It is extinguished by subsequent positive movement at Step 4, which is the difference between recording adverse movement and abandoning it.

Status Re-evaluation

After allocation, contractual status must be recalculated.

All evaluation uses the same reference:

balanceProcessedDate

Instalment State

For each instalment, evaluate in this order and stop at the first match:

if unpaidAmount <= tolerance                              -> Paid
else if dueDate + graceDays <= balanceProcessedDate       -> Missed
else if dueDate <= balanceProcessedDate                   -> Due
else if paidAmount > 0                                    -> PartiallyPaid
else                                                      -> Pending

Order is fixed rather than incidental. Evaluating date before allocation reports fully paid instalments as missed.

Next Payable Instalment

Find the first instalment in ascending sequenceNumber where:

unpaidAmount > tolerance

Set nextUnpaid = true. All others are set to false. Where no such instalment exists, no instalment carries the flag.

This ensures exactly one authoritative next instalment while any remain unpaid.

Persisted Metadata

Balance-only allocation is only safe if decisions can be reconstructed.

Each run must persist:

baseline
delta
offsetApplied
appliedDelta
overpaidAmount
unappliedNegativeDelta
balanceProcessedDate
lastBalanceProcessedDate
lastApportionedBalance

offsetApplied is new. Without it the audit record cannot explain why a delta of 140 produced 120 of allocation, which defeats the purpose of persisting the metadata at all.

Persistence must be atomic.

If baseline updates without allocation, future deltas become corrupted.

Baseline Reset

The earlier version required a baseline reset on schedule mutation but did not define one, which left the most dangerous operation in the model undefined.

A baseline reset is required when any of the following occur:

the instalment schedule is added to, removed from, or re-amounted
the arrangement is renegotiated
a reconciliation resolves an accumulated unappliedNegativeDelta by external decision
a restated snapshot is accepted after investigation

The reset procedure is:

lastApportionedBalance = currentBalance
lastBalanceProcessedDate = balanceProcessedDate
unappliedNegativeDelta = 0
overpaidAmount = 0

Instalment allocation is not cleared. A reset re-anchors the baseline to the present observation and abandons the ability to explain movement across the reset boundary. It is therefore an audited operation with a recorded reason, not a routine one, and no delta is computed on the run that performs it.

Edge Case Stress Tests

Duplicate Snapshot Replay

If the same snapshot is processed twice:

delta = 0

No mutation occurs. The model is idempotent.

Restated Snapshot

Same balanceProcessedDate, different balance. Rejected at Step 1 and flagged. Accepting it requires a baseline reset with a recorded reason.

Out-of-Order Snapshot

Older snapshots arriving after newer ones distort delta.

reject if balanceProcessedDate < lastBalanceProcessedDate

Balance Oscillation

If balance decreases then later increases:

positive delta allocates
negative delta accumulates unappliedNegativeDelta
the next positive delta extinguishes it before allocating

Instalments remain stable throughout.

Fee Then Settlement

A fee raises the balance, then a payment clears the account. Adverse movement is offset first and the residual allocates. This case produced a spurious overpayment in the earlier version and is the reason Step 4 exists.

Overpayment Beyond Schedule

If, after offset:

delta > totalUnpaid

All instalments are fully paid and the remaining value becomes overpaidAmount.

Prolonged Snapshot Absence

No snapshot arrives for an extended period. The model computes nothing and mutates nothing, because delta requires two observations. Instalment states continue to be reported against lastBalanceProcessedDate, not today's date.

This is worth stating explicitly: status is as at the last trusted snapshot, and an integration outage means the reported status is stale rather than wrong. A consumer that treats these states as current is making an assumption this model does not support.

Schedule Mutation

If instalment structure changes without a baseline reset, allocation becomes misaligned against a baseline that reflects a schedule which no longer exists. Any mutation of the schedule requires a baseline reset in the same atomic operation.

Baseline Corruption

If lastApportionedBalance is incorrect, all future deltas compound the error. Baseline must only update after successful atomic allocation. Invariant 7 detects the condition on the next run.

When to Use

This model is appropriate when:

only arrears balance snapshots are available
transaction level data is unavailable
idempotent processing is required
allocation must be deterministic and auditable
instalments follow sequential contractual ordering

When Not to Use

Do not use this model when:

full transaction feeds are available
allocation rules require dynamic prioritisation
automatic retroactive reversals are required
instalment schedules mutate frequently
allocation must map to specific payment events
the host supplies outstanding balance rather than arrears

In those cases a transaction driven allocation model is structurally superior.

Known Failure Conditions

The model is deterministic but not immune to structural misalignment.

Condition	Detection
Corrupted `lastApportionedBalance`	Invariant 7 fails on next run
Out-of-order snapshot processing	Rejected at Step 1
Restated snapshot	Rejected at Step 1
Instalment structure mutation without reset	Invariant 1 or 7 fails
Tolerance misconfiguration	Repeated sub-tolerance deltas, or arrears masked as paid
Accumulating `unappliedNegativeDelta`	Threshold alert on age and value
Baseline updated without atomic allocation	Invariant 7 fails on next run

The earlier version asserted that all of these are detectable without saying by what. Each now names its detection mechanism, and where the mechanism is an invariant the failure surfaces automatically rather than on inspection.

Hard Constraints

If any of the following are violated, determinism collapses.

Deterministic ordering of instalments
Delta-only allocation
No implicit reversal
Adverse movement offset before allocation
Atomic persistence
Chronological snapshot processing
All derived values stored as explicit state

These are structural rules, not implementation details.

Structural Validation Questions

Before production deployment, these questions must be answerable.

Can I prove lastApportionedBalance reflects a fully persisted allocation state?
Have I enforced monotonic processing of balanceProcessedDate?
Is adverse movement offset before allocation, and is offsetApplied persisted?
Under what conditions is the baseline reset, and who authorises it?
Does tolerance prevent rounding drift without masking real arrears, and is it applied to the delta as well as to unpaid amounts?
Can I replay any historical allocation using only persisted metadata?
Does invariant 7 hold on every run, and what happens when it does not?

If any answer is unclear, the implementation contains structural risk.

Worked Example

A concrete example makes the model easier to reason about.

Assume an arrangement with four instalments and graceDays = 0, tolerance = £0.01.

Sequence	Due Date	Scheduled	Paid	Unpaid
1	2026-01-05	£100	£0	£100
2	2026-02-05	£100	£0	£100
3	2026-03-05	£100	£0	£100
4	2026-04-05	£100	£0	£100

Arrangement-level state at creation:

{
  "arrangementCreatedDate": "2026-01-01",
  "balanceAtArrangementCreation": 400,
  "lastApportionedBalance": 400,
  "lastBalanceProcessedDate": null,
  "unappliedNegativeDelta": 0,
  "overpaidAmount": 0
}

Total arrears is £400.

Snapshot 1: Balance Decreases

{
  "balanceProcessedDate": "2026-02-10",
  "currentBalance": 250
}

baseline = 400
delta    = 400 - 250 = 150
offset   = 0

Allocation waterfall:

Instalment 1 receives £100. Paid £100, unpaid £0, remaining £50.
Instalment 2 receives £50. Paid £50, unpaid £50, remaining £0.

Sequence	Due Date	Scheduled	Paid	Unpaid	State	nextUnpaid
1	2026-01-05	£100	£100	£0	Paid	false
2	2026-02-05	£100	£50	£50	Missed	true
3	2026-03-05	£100	£0	£100	Pending	false
4	2026-04-05	£100	£0	£100	Pending	false

Instalment 2 is Missed because its due date plus grace has passed relative to balanceProcessedDate and unpaid exceeds tolerance.

Conservation check: 400 - 250 = 150, and sum(paid) + overpaid - unapplied = 150 + 0 - 0 = 150. Invariant 7 holds.

{
  "baseline": 400,
  "delta": 150,
  "offsetApplied": 0,
  "appliedDelta": 150,
  "overpaidAmount": 0,
  "unappliedNegativeDelta": 0,
  "balanceProcessedDate": "2026-02-10",
  "lastApportionedBalance": 250
}

Snapshot 2: Balance Decreases Again

{
  "balanceProcessedDate": "2026-03-07",
  "currentBalance": 120
}

baseline = 250
delta    = 250 - 120 = 130
offset   = 0

Instalment 2 receives £50. Paid £100, unpaid £0, remaining £80.
Instalment 3 receives £80. Paid £80, unpaid £20, remaining £0.

Sequence	Due Date	Scheduled	Paid	Unpaid	State	nextUnpaid
1	2026-01-05	£100	£100	£0	Paid	false
2	2026-02-05	£100	£100	£0	Paid	false
3	2026-03-05	£100	£80	£20	Missed	true
4	2026-04-05	£100	£0	£100	Pending	false

Conservation check: 400 - 120 = 280, and 280 + 0 - 0 = 280. Holds.

Snapshot 3: Balance Increases

{
  "balanceProcessedDate": "2026-03-08",
  "currentBalance": 140
}

baseline = 120
delta    = 120 - 140 = -20

Because delta is negative, the model does not reverse instalment state.

unappliedNegativeDelta += 20

Instalment state remains unchanged. This is deliberate. The signal does not tell us whether the increase came from a fee, a reversal, a correction, or some other adjustment, so the model records it rather than inventing a reversal.

Conservation check: 400 - 140 = 260, and 280 + 0 - 20 = 260. Holds, and note that the adverse movement term is what makes it hold.

{
  "baseline": 120,
  "delta": -20,
  "offsetApplied": 0,
  "appliedDelta": 0,
  "overpaidAmount": 0,
  "unappliedNegativeDelta": 20,
  "balanceProcessedDate": "2026-03-08",
  "lastApportionedBalance": 140
}

Snapshot 4: Settlement With Adverse Movement Outstanding

{
  "balanceProcessedDate": "2026-04-10",
  "currentBalance": 0
}

baseline = 140
delta    = 140 - 0 = 140

Offset step:

offset = min(140, 20) = 20
delta  = 140 - 20 = 120
unappliedNegativeDelta = 0

Current unpaid across the schedule is £120: instalment 3 at £20 and instalment 4 at £100.

Instalment 3 receives £20. Unpaid £0, remaining £100.
Instalment 4 receives £100. Unpaid £0, remaining £0.

All instalments are fully paid. overpaidAmount remains £0.

{
  "baseline": 140,
  "delta": 140,
  "offsetApplied": 20,
  "appliedDelta": 120,
  "overpaidAmount": 0,
  "unappliedNegativeDelta": 0,
  "balanceProcessedDate": "2026-04-10",
  "lastApportionedBalance": 0
}

Conservation check: 400 - 0 = 400, and sum(paid) + overpaid - unapplied = 400 + 0 - 0 = 400. Holds.

What changed from the earlier version

Without Step 4, this snapshot produced a different and incorrect result. The full £140 reached the waterfall, £120 satisfied the schedule, and £20 was booked as overpaidAmount while unappliedNegativeDelta remained at £20.

The account then reported £20 overpaid and £20 of unresolved adverse movement at the same time. Both figures described the same £20, once as money received in excess and once as balance increase never accounted for. The customer had not overpaid by a penny. They had paid a £20 fee.

The old conservation check makes it obvious: 400 - 0 = 400, but 400 + 20 - 20 = 400 only because the two errors cancel in the total while both remain wrong individually, and any process consuming overpaidAmount acts on a refund that is not owed.

What This Demonstrates

Allocation is incremental, not full recomputation.
The waterfall is strictly sequence based.
Negative delta is recorded, not inferred as reversal, and is extinguished by later positive movement rather than accumulating indefinitely.
Status evaluation uses balanceProcessedDate, not processing time.
Overpayment is preserved explicitly, and only arises where value genuinely exceeds both the schedule and any outstanding adverse movement.

State Diagram: Meaning of Each Stage

SnapshotReceived

A host snapshot arrives with an arrears balance and a balance processed date. At this point nothing is trusted.

ValidateSnapshot

The snapshot is accepted only if it is structurally safe to process. Rejection conditions: it predates arrangement creation, it is older than the last trusted processed snapshot, it restates a date already processed with a different balance, or the balance is null or negative.

This protects the state model from back-propagation, out-of-order mutation, and double counting.

DetermineBaseline

The system chooses the reference point against which movement is measured. First run uses balanceAtArrangementCreation. Later runs use lastApportionedBalance. All later logic depends on baseline integrity.

ComputeDelta

delta = baseline - currentBalance

Movement within tolerance exits without mutation. The model does not reconstruct historical transactions or replay the schedule from scratch.

OffsetAdverseMovement

Positive movement first extinguishes any accumulated unappliedNegativeDelta. Only the residual is allocatable. This stage is the difference between a model that records adverse movement and one that resolves it.

PositiveDelta

If the residual is greater than zero, arrears has reduced by more than any outstanding adverse movement, and that reduction is eligible for instalment allocation.

AllocateWaterfall

The system allocates sequentially in ascending sequence number. This is where positive balance movement converges into contractual payment state.

NegativeDelta

If delta is negative, arrears increased. The model refuses to guess whether this reflects fees, reversals, or adjustments, so it does not mutate instalments.

RecordNegativeDelta

The increase is captured as unappliedNegativeDelta, preserving visibility without silently undoing prior state, and remains until offset by later positive movement or cleared by an audited baseline reset.

ZeroDelta

If movement is within tolerance, allocation state is unchanged. This is what makes duplicate snapshot replay safe.

RecalculateStatuses

The system recalculates instalment states and the next unpaid instalment, both derived from balanceProcessedDate. This keeps payment state and contractual status aligned to the same temporal reference.

PersistState

All changes are persisted atomically: arrangement metadata, instalment state, baseline progression, and audit metadata including offsetApplied. If this step is not atomic, future delta calculations become unsafe.

Converged

The latest trusted snapshot has been incorporated into a deterministic state. This is the new trusted point for the next run.

Unresolved Tensions

Two conditions this model does not resolve.

Adverse movement has no attribution. The model records balance increases without knowing whether they are fees, reversals, or corrections, and offsets them uniformly against later positive movement. Where the increase was a genuine payment reversal, the offset silently absorbs it and the reversed payment remains allocated to instalments it no longer satisfies. Resolving this requires an adjustment record from the host, which an arrears-only integration by definition does not provide. The condition is detectable only through the age and size of accumulated adverse movement, which is why the alert in the failure table exists.

Overpayment terminates here. overpaidAmount accumulates as explicit state with no defined consumer. The model deliberately does not refund, reallocate, or offset it against future schedules, because each of those is a commercial decision rather than a structural one. An implementation that leaves it unconsumed has a growing figure that nothing acts on, and that is a gap in the surrounding system rather than in this model, but it is a gap this artefact creates.

Revised: Arrears Delta Apportionment