Summary

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
a sequential waterfall across instalments

Negative balance movement does not reverse prior allocations. Instead, it is recorded explicitly as state.

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:

total arrears balance or outstanding balance
balanceProcessedDate

I do not receive payment events.

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.

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 problemsz.
Every run must persist enough metadata to reconstruct allocation deterministically.

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
unappliedNegativeDelta
overpaidAmount

Instalment-Level State

sequenceNumber
dueDate
scheduledAmount
unpaidAmount
paidAmount
isMissed
nextUnpaid

Tolerance

A configurable tolerance defines what counts as effectively zero unpaid.

This protects against rounding drift.

State Invariants

These invariants must always hold.

paidAmount + unpaidAmount = scheduledAmount
Only one instalment may have nextUnpaid = true
paidAmount cannot decrease through delta processing
Negative delta does not mutate instalment state
Allocation order is strictly ascending sequenceNumber

Allocation Lifecycle

Step 1 — Validate Snapshot

If:

balanceProcessedDate < arrangementCreatedDate

Exit without mutation.

Host state must not back-propagate into a schedule that did not exist.

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 last trusted state.

Only this value is eligible for allocation.

The system never recomputes from scratch.

It only applies incremental movement since last convergence.

Positive Delta Allocation

If:

delta > 0

The balance decreased.

This is interpreted as net payment 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 adjustments

Given identical state and delta, allocation is identical.

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.

Status Re-evaluation

After allocation, contractual status must be recalculated.

All evaluation uses the same reference:

balanceProcessedDate

Missed Instalments

For each instalment:

if dueDate <= balanceProcessedDate
and unpaidAmount > tolerance
then isMissed = true
else isMissed = false

Next Payable Instalment

Find the first instalment where:

unpaidAmount > tolerance

Set:

nextUnpaid = true

All others are set to false.

This ensures exactly one authoritative next instalment.

Persisted Metadata

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

Each run must persist:

baseline
delta
appliedDelta
overpaidAmount
unappliedNegativeDelta
balanceProcessedDate
lastApportionedBalance

Persistence must be atomic.

If baseline updates without allocation, future deltas become corrupted.

Edge Case Stress Tests

Duplicate Snapshot Replay

If the same snapshot is processed twice:

delta = 0

No mutation occurs.

The model is idempotent.

Out-of-Order Snapshot

Older snapshots arriving after newer ones distort delta.

Constraint:

reject if balanceProcessedDate < lastProcessedDate

Balance Oscillation

If balance decreases then later increases:

positive delta allocates
negative delta accumulates unappliedNegativeDelta

Instalments remain stable.

Overpayment Beyond Schedule

If:

delta > totalUnpaid

All instalments are fully paid.

Remaining value becomes overpaidAmount.

Schedule Mutation

If instalment structure changes without baseline reset, allocation becomes misaligned.

Constraint: If there is is to be a mutation of the and aky key component then they should be a baseline reset

Baseline Corruption

If lastApportionedBalance is incorrect, all future deltas compound the error.

Baseline must only update after successful atomic allocation.

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 prioritization
automatic retroactive reversals are required
instalment schedules mutate frequently
allocation must map to specific payment events

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

Known Failure

The model is deterministic but not immune to structural mis-alignment.

Primary risks include:

corrupted lastApportionedBalance
out-of-order snapshot processing
instalment structure mutation
tolerance misconfiguration
unresolved accumulation of unappliedNegativeDelta
baseline updates without atomic allocation

All of these failure posibilities are detectable.

Hard Constraints

If any of the following constraints are violated, determinism collapses.

Deterministic ordering of instalments
Delta-only allocation
No implicit reversal
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?
What explicit process resolves unappliedNegativeDelta?
Under what conditions is the baseline reset?
Does tolerance prevent rounding drift without masking real arrears?
Can I replay any historical allocation using only persisted metadata?

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

Summary

Given only a daily arrears balance snapshot, I cannot reconstruct transactions.

However, I can define a deterministic state progression that converges safely on balance movement.

Payment apportionment in arrears-only integrations is therefore not transaction matching.

It is:

Controlled, constraint-driven state convergence based on the only signal that can be trusted.

Worked Example

A concrete example makes the model easier to reason about.

Assume an arrangement with four instalments.

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,
  "unappliedNegativeDelta": 0,
  "overpaidAmount": 0
}

At this point, total arrears is £400.

Snapshot 1: Balance Decreases A new trusted snapshot arrives:

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

Baseline:

Baseline = 400

Delta:

delta = baseline - currentBalance
delta = 400 - 250
delta = 150

Because delta > 0, £150 is eligible for allocation.

Allocation waterfall:

Instalment 1 receives £100

paid = £100
unpaid = £0
remaining = £50

2.Instalment 2 receives £50

paid = £50
unpaid = £50
remaining = £0

Updated instalment state:

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

Why is instalment 2 missed?

Because:

dueDate <= balanceProcessedDate
unpaidAmount > tolerance

Persisted arrangement-level state becomes:

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

Snapshot 2: Balance Decreases Again

Another trusted snapshot arrives:

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

New baseline:

baseline = lastApportionedBalance = 250

Delta:

delta = 250 - 120 = 130

Allocation waterfall:

Instalment 2 receives £50

paid = £100
unpaid = £0
remaining = £80

2.Instalment 3 receives £80

paid = £80
unpaid = £20
remaining = £0

Updated instalment state:

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

Persisted arrangement-level state:

{
  "baseline": 250,
  "delta": 130,
  "appliedDelta": 130,
  "overpaidAmount": 0,
  "unappliedNegativeDelta": 0,
  "balanceProcessedDate": "2026-03-07",
  "lastApportionedBalance": 120
}

Snapshot 3: Balance Increases

A later snapshot arrives:

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

base line:

baseline = 120

Delta:

delta = 120 - 140 = -20

Because delta < 0, the model does not reverse instalment state.

Instead:

unappliedNegativeDelta += 20

Updated arrangement-level state:

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

Instalment state remains unchanged. This is deliberate.

The signal does not tell us whether the increase came from:

a fee
a reversal
a correction
some other adjustment So the model records the increase explicitly instead of inventing a reversal.

Snapshot 4: Overpayment Case

Assume a later trusted snapshot:

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

Current baseline:

baseline = 140

Delta:

delta = 140 - 0 = 140

Current unpaid across instalments:

Instalment 3 unpaid = £20
Instalment 4 unpaid = £100

Total unpaid = £120

Allocation waterfall:

Instalment 3 receives £20

unpaid becomes £0
remaining = £120

2.Instalment 4 receives £100

unpaid becomes £0
remaining = £20 All instalments are now fully paid.

Remaining £20 becomes:

overpaidAmount += 20

Final arrangement-level state:

{
  "overpaidAmount": 20
}

This shows an important property of the model:

Excess positive delta is not discarded. It is captured explicitly as state.

Worked Example: What This Demonstrates

This example shows five important properties of the model.

Allocation is incremental, not full recomputation.
The waterfall is strictly sequence-based.
Negative delta is recorded, not inferred as reversal.
Status evaluation uses balanceProcessedDate, not processing time.
Overpayment is preserved explicitly instead of being silently truncated.

State Diagram: Meaning of Each Stage

SnapshotReceived

A host snapshot arrives with:

arrears balance
balance processed date At this point, nothing is trusted yet.

ValidateSnapshot

The snapshot is accepted only if it is structurally safe to process. Examples of rejection conditions:

it predates arrangement creation
it is older than the last trusted processed snapshot This protects the state model from back-propagation and out-of-order mutation.

DetermineBaseline

The system chooses the reference point against which balance movement will be measured.

[-] first run: use balanceAtArrangementCreation [-] later runs: use lastApportionedBalance

This step is critical because all later logic depends on baseline integrity.

ComputeDelta

The system calculates:

delta = baseline - currentBalance

This is the only allocatable input.

The model does not reconstruct historical transactions or replay the schedule from scratch.

PositiveDelta

If * delta > 0 *, arrears has reduced.

That reduction is treated as value eligible for instalment allocation.

The model proceeds into the contractual waterfall.

AllocateWaterfall

The system allocates delta sequentially across instalments in ascending sequence number.

This is where the model converges positive balance movement into contractual payment state.

NegativeDelta

If ** delta < 0 **, arrears increased.

The model refuses to guess whether this increase reflects:

fees
reversals
adjustments

So it does not mutate instalments.

RecordNegativeDelta

The increase is captured explicitly as:

unappliedNegativeDelta

This preserves visibility without silently undoing prior state.

ZeroDelta

If delta = 0, no balance movement occurred relative to baseline.

The allocation state remains unchanged.

This is what makes duplicate snapshot replay safe.

RecalculateStatuses

After delta handling, the system recalculates:

missed instalments
next unpaid instalment

These are derived from the same temporal reference:

balanceProcessedDate

This keeps payment state and contractual status aligned.

PersistState

All changes must be persisted atomically.

That includes:

updated arrangement metadata
updated instalment state
baseline progression
audit metadata

If this step is not atomic, future delta calculations become unsafe.

Converged

At this point, the system has safely incorporated the latest trusted snapshot into a deterministic state.

This is the new trusted point for the next run.