# V105 — Synthetic monthly transfer and cash ledger

29 October 2026. Implemented, independently tested accounting prototype. Synthetic scenarios only; no empirical calibration, causal approval or integration into v71–v101.

## Main finding
An annual transfer total cannot establish when consumption can be paid. This prototype makes that timing restriction explicit.

| Illustrative case | Paid transfer in 2026 | Realized baseline consumption in 2026 | Unmet desired consumption | Household cash at year end |
|---|---:|---:|---:|---:|
| Receipt in January | 120 | 120 | 0 | 0 |
| Same receipt in December | 120 | 10 | 110 | 110 |

Each household starts with zero cash and needs 10 per month. Treasury starts with 120, there are no wages or new loans, and prices are fixed at 1. The incremental-demand kernel is zero in this timing comparison: all desired consumption is the same fixed baseline in both paths. This deliberately isolates cash availability. Unmet desired consumption is not a purchased good, a new loan or an automatic future purchase. The late receipt cannot retrospectively finance January–November spending.

This is an accounting example, not an estimated effect of delaying real-world benefits. It does not identify a permanent-transfer MPC or forecast the thesis scenario.

## Implemented scope
Code: scripts/monthly_transfer_v105.py. Tests: scripts/test_monthly_transfer_v105.py.

Four cash accounts represent one fixed household cohort, treasury, a combined goods market/employer and a lender. Every cash movement records payer, recipient, amount and month. Initial treasury cash is an explicit synthetic endowment; no tax-capacity assumption is estimated.

Declared order within each month is wages, funded transfer, requested borrowing subject to lender cash, interest obligations including previous arrears, principal subject to outstanding debt, and consumption subject to remaining cash. This monthly order is an assumption; it does not certify daily solvency. Unfunded transfers and credit requests are separately reported.

The household cash identity and the sum of all four cash accounts are checked every month. Loan advances increase matching household principal debt and lender claim; principal payments reduce both and do not enter consumption. Unpaid interest is a separate noncompounding arrears claim; scheduled unpaid principal remains in debt. No automatic rollover borrowing, interest capitalization or default/write-off is implemented. Claim values remain contractual amounts.

Baseline desired consumption excludes the incremental transfer. A finite, causal convolution of the explicitly supplied kernel with actually paid transfers is added exactly once. The prototype accepts nonnegative kernel weights with cumulative weight at most one; this is a scenario restriction, not a behavioral law. Desired response and actual spending differ when cash or debt service constrains the household. Actual incremental consumption is the difference between paired runs, not automatically the desired response.

## Calendar and aggregation
Inputs require consecutive YYYY-MM months, positive price indices, finite nonnegative flows and positive fixed cohort mass. Year zero is rejected as a cash-flow period; opening stocks are separate inputs. Real spending is deflated month by month before annual summation; per-person outputs divide aggregate spending by cohort mass once.

Annual flows are summed and closing stocks use the final reported month. Incomplete calendar years are labeled. December closing cash carries into January opening cash. The output reports any desired kernel-response tail outside the supplied schedule; an omitted tail is not silently set to zero.

A separate fully funded example pays 100 in December with an illustrative kernel [.5, .25, .25], resulting in spending of 50, 25 and 25 in December, January and February. Fourteen months are reported, so that tail is included. A paired zero-transfer baseline uses the same opening stocks, prices and schedule. The resulting difference of 100 follows from these chosen assumptions; it is not validation of the kernel or evidence for benefit effectiveness.

## Acceptance coverage
All ten v104 acceptance cases are exercised by the test suite:
- zero transfer; single receipt with no anticipation;
- December/January continuity and explicit truncated tail;
- identical annual transfer totals with different monthly cash feasibility;
- principal classification and matching lender claims;
- constrained spending, rejected negative opening cash and declared financing;
- year-zero exclusion, cohort-mass reconciliation and monthly deflation.

Additional cases cover insufficient treasury funding, interest priority and arrears, invalid schedules/kernels and reproducible paired output. Fifteen tests passed locally; the suite is also added to the existing research CI job. Scenario output is reproducible with:
```
python scripts/test_monthly_transfer_v105.py
python scripts/monthly_transfer_v105.py --output data/processed/monthly_transfer_v105.json
```
All archived examples have zero reported cash/debt identity residual. These checks establish accounting consistency for this implementation, not empirical accuracy.

## Remaining gates and next step
The isolated monthly ledger and its synthetic tests are complete. The wider v104 contract is not fully implemented: multiple interacting household cohorts, asset purchases/sales and valuation, housing/rent/mortgage separation, endogenous tax receipts, firm investment and macro feedback remain outside this prototype. Cash held after spending is an end-of-period stock, not a second expenditure or measured voluntary-saving preference.

No annual simulator rules or historical results were replaced. The next integration gate is an adapter with explicit annual-to-monthly timing assumptions, a fixed accounting baseline and reconciliation of treasury, household and firm resources. It must preserve the annual reference when no incremental response is enabled and expose changes caused by payment dates rather than manufacture monthly observations. Empirical source matching and calibration remain closed.

The current restricted-data route remains closed as recorded in v104. No participant records or new source estimates were used.

[Monthly traces and counterpart transactions](data/processed/monthly_transfer_v105.json) · [V104 contract](MONTHLY_TRANSFER_CONTRACT_V104.md) · [V103 source-estimand limits](TRANSFER_ESTIMANDS_V103.md)