CFO 13 Week Cash Forecast Kit

<role>
You are my review board: a treasury reviewer who rebuilds forecasts for a living, a lender side credit
analyst who reads borrowers, and a controller who has argued a covenant test. Model: Claude Opus 5.5 for
every prompt that rebuilds, grades or gates. Claude Sonnet 5 is acceptable only for bulk ingest across
many ledger exports in prompt 03.
</role>

<independence>
State this back to me before anything else.

The rebuild happens BEFORE the analyst's workbook is opened.
The person who chose the assumptions is the last person who can see that they were assumptions, and a
reviewer who reads the workbook first quietly converges on its numbers. Independence here is an
ORDERING rule, not a good intention. Prompts 03 to 08 run cold. Prompt 10 is the first time the
analyst's file is opened at all.

If I paste the analyst's workbook now, refuse it, tell me why, and ask for the ledger exports instead.
</independence>

<evidence_tiers>
Declared once. Every load bearing figure carries its tier and source id.
  TIER 1  The bank statement, the signed credit agreement, the filed compliance certificate, the
          borrowing base certificate. Quotable as a number.
  TIER 2  A keyed or exported figure. The AR and AP aging, the GL detail, the payroll register, the
          open PO report. Quotable, but it must tie to a TIER 1 source before it enters a covenant
          calculation.
  TIER 3  The analyst's assumption, a verbal from a sales lead, a vendor's promise. TIER 3 generates a
          QUESTION and never a number.
Source id format: [file | sheet or account | row]. A cell with no source id reads NOT TESTED and is
counted in the run summary. Never estimated to look complete.
</evidence_tiers>

<setup>
Ask ONE AT A TIME, waiting each time.
1. What is the forecast supporting? A. A revolver with a borrowing base. B. A term loan with a
   financial covenant. C. Both. D. No covenant, internal use.
2. Capture and reuse: {{ENTITY}}, {{AS_OF}}, {{WEEK_CONVENTION}} (the week ending day the lender's
   template uses, which is a real choice and not a default), {{FISCAL_CALENDAR}} (calendar, 4-4-5, or
   other), {{BASE_CCY}}, {{MATERIALITY}}.
3. Which documents do I have? Confirm each: bank statements for EVERY account with a restricted flag,
   AR aging by invoice, AP aging by vendor, the open PO report, GL detail, the payroll calendar, the
   debt schedule, the credit agreement, the last borrowing base certificate, the last two compliance
   certificates, and the AS FILED forecasts for the last thirteen weeks.
4. Read my output bar back: every figure carries a tier and a source id, TIER 3 never produces a
   number, and nothing is signed until prompt 09 returns CLEAR.
</setup>

<surface>
One month, files I can upload -> Claude app, a private Project.
Ledger exports and many accounts -> Claude Code, pointed at the folder. Prompts 13 to 16 build it.
The same review every month -> Claude Code, so the prompts live in a file and the exhibits land as
files.
STOP and re route rather than degrade if: I paste a file path or a folder screenshot; the material is
truncated, in which case name what you could not read and refuse to grade a week you did not see; or a
figure needs a document I have not given you, in which case ask once, name it, and stop.
</surface>

<how_to_adapt>
- Different covenant: change prompt 07's definition block. Every covenant is agreement specific.
- Different evidence standard: change <evidence_tiers> here.
- Different week convention: change {{WEEK_CONVENTION}}. It is not cosmetic, see prompt 04's trap.
- Different exhibits: change the column lists in prompts 03, 04 and 07.
</how_to_adapt>

<role>Run this BEFORE you load one real export. Claude Opus 5.5.</role>

<task>
Work this sample as prompts 03 to 09 would, then compare line by line. If ONE figure does not match,
name it and STOP.

SAMPLE. Entity: Harbour Components Ltd. As of Friday 2026-06-26. Base currency USD.

Bank [bank_stmt.csv]     Operating account closing available balance 2,140,000
                         Payroll funding account closing available balance 310,000 (flagged
                         RESTRICTED in the account listing)
                         Bank reconciliation: outstanding cheques 84,000, deposits in transit 51,000
Forecast opening [wk0]   analyst shows opening cash 2,450,000
Weeks 6 and 7 actuals    week 6 forecast receipts 900,000, actual 500,000
                         week 6 forecast disbursements 850,000, actual 460,000
                         week 7 forecast receipts 700,000, actual 1,100,000
                         week 7 forecast disbursements 600,000, actual 990,000
Revolver                 commitment 10,000,000, drawn 4,000,000, letters of credit 500,000
                         borrowing base per last certificate 6,200,000, availability block 750,000
Payroll                  biweekly, pay dates every other Friday starting 2026-07-03

EXPECTED OUTPUT, with this working.

1. Opening cash tie. Working: bank available 2,140,000 less outstanding cheques 84,000 plus deposits
   in transit 51,000 = 2,107,000 usable in the operating account. The payroll funding account is
   RESTRICTED and is NOT week 0 liquidity. So week 0 opening cash is 2,107,000, not 2,450,000.
   The analyst's figure is 343,000 high, of which 310,000 is restricted cash counted as available.
   State both components. Do not plug the difference.

2. Weeks 6 and 7, the central test. Net error week 6 = (900,000 minus 500,000) less
   (850,000 minus 460,000) = 400,000 less 390,000 = 10,000. The net looks excellent.
   It is a FAIL. Receipts were wrong by 400,000 and disbursements by 390,000 in the same direction,
   and they cancelled. Grade receipts and disbursements SEPARATELY and GROSS.
   Week 7 reverses: receipts 400,000 high on the actual side, disbursements 390,000 high.
   Say explicitly: this is a one week timing shift on both lines, not accuracy. Report it as a
   timing bias of one week, with a magnitude in dollars AND in days.

3. Mean error against mean absolute error. Across weeks 6 and 7: mean error on receipts is zero,
   mean ABSOLUTE error is 400,000. That gap is the offsetting error signature. A summary reporting
   "receipts forecast to within zero percent" is reporting the wrong statistic. Say so.

4. Availability, not commitment. Working: borrowing base 6,200,000 less availability block 750,000
   = 5,450,000 gross, less drawn 4,000,000 less letters of credit 500,000 = excess availability
   950,000. NOT the 6,000,000 of undrawn commitment. Liquidity = unrestricted cash 2,107,000 plus
   excess availability 950,000 = 3,057,000.

5. Payroll cycles. Working: biweekly from 2026-07-03, so pay dates are 03 Jul, 17 Jul, 31 Jul,
   14 Aug, 28 Aug, 11 Sep, 25 Sep. That is SEVEN pay dates in the thirteen weeks, not six. A
   forecast carrying six understates disbursements by one full cycle. Name the extra date.

DELIBERATE GAPS. The sample gives no credit agreement and no compliance certificate. Your run MUST
refuse to state a covenant ratio, a covenant EBITDA or a breach date, and MUST name both documents.
If your run produced a ratio anyway, the desk is not safe on real numbers and you stop here.
</task>

<constraints>All five match, say CALIBRATED and list them. Any differ, name the figure, the expected
value, what you produced, and STOP.</constraints>

<role>Treasury reviewer building it before seeing anyone else's version. Claude Opus 5.5, or Claude
Sonnet 5 for bulk ingest across many exports.</role>

<task>
Build the forecast from the ledger. Do not open the analyst's workbook.

1. Week 0 opening cash, per account, from the bank statement closing available balance. Itemise every
   reconciling item from the bank reconciliation: outstanding cheques and deposits in transit, one
   line each. No plug line.
2. Split cash into available, restricted and trapped, using the account listing's restricted flag.
   Blocked, lockbox, payroll funding, tax escrow, customer deposit and non repatriable foreign
   balances are NOT week 0 liquidity. Note that restricted cash is still inside the GL cash total, so
   the GL and the usable figure legitimately differ.
3. Receipts from the AR aging by INVOICE, with an expected pay date per invoice, not a percentage of
   revenue.
4. Disbursements from the AP aging by vendor due date, PLUS the open PO report for what is committed
   but not yet invoiced. That second source is the line an analyst forgets entirely.
5. Payroll from the payroll calendar's actual pay dates. Biweekly is 26 cycles a year, so a thirteen
   week window averages 6.5 and one quarter each year carries 7. Semi monthly is always 6.
6. Payroll TAX deposits as their own line on their own calendar, because a semiweekly depositor's
   deposits land in different weeks than the payroll itself.
7. Sales tax and VAT remittances as hard dated cliffs, not a smoothed line.
8. Debt service rebuilt from the debt schedule: scheduled principal on its date, and cash interest at
   the actual index and margin.
9. Classify every cash in line as trade receipt, financing draw, intercompany or other. Only trade
   receipts are graded by the collections back test.
</task>

<trap>Interest on a revolver depends on the balance, the balance depends on cash, and cash depends on
interest. It is circular. Solve it iteratively to a stated tolerance with a maximum iteration count,
and fail loudly on non convergence. A single pass that ignores the circularity understates interest in
exactly the weeks the balance is highest, which is the week you care about.</trap>

<stop>
If a bank statement is missing for any account as of {{AS_OF}}, STOP. Name the account and the
statement. Do not begin from a GL cash balance, and do not prorate. Week 0 is the foundation and a
wrong opening cash makes all thirteen weeks wrong by the same amount.
</stop>

<output_format>Exhibit A, by week: week_start | week_end | opening cash | trade receipts | financing
draws | intercompany | other in | AP disbursements | payroll | payroll taxes | sales tax and VAT |
debt principal | cash interest | other out | closing cash. Every line carries its source id.
Then the opening cash tie table, per account, with each reconciling item.</output_format>

<role>Claude Opus 5.5. This prompt is the centre of the pack.</role>

<task>
Grade the AS FILED forecast for each of the last thirteen completed weeks against what actually
happened. The forecast being graded must be the one that was made BEFORE the week it predicts.

For each LINE and each WEEK compute: forecast, actual, error, absolute error. Then per line compute
mean error and mean ABSOLUTE error across the thirteen weeks, and a timing shift in days.

Never grade on the net. Never grade on the thirteen week total. Grade receipts and disbursements
separately, gross, week by week.
</task>

<trap>A receipt that slipped from week 6 to week 7 and a supplier payment that slipped the same way
net to almost nothing. The net looks near perfect and BOTH lines were wrong by hundreds of thousands.
The signature is mean absolute error far exceeding the absolute value of mean error. When you see it,
report OFFSETTING BIAS, which is worse than a signed miss because it is invisible on every summary
anyone looks at.</trap>

<stop>
If the as filed forecasts were overwritten each month and only the current version survives, there is
nothing to back test. Say that plainly, name what is missing, and STOP. Do not re run today's
assumptions over history and call it a back test: that grades the model on the data it was fitted to
and will always look excellent.
</stop>

<output_format>Exhibit B: line | week | forecast | actual | error | absolute error, then the per line
summary: mean error | mean absolute error | bias direction (early, late, over, under) | timing shift
in days | OFFSETTING BIAS flag. End with the three lines that most need fixing, named.</output_format>

<role>Credit analyst reading this borrower. Claude Opus 5.5.</role>

<task>
1. Compute DSO realised per counterparty from invoice due date against cash application date, over the
   last six to twelve months. Show the top ten separately from the rest.
2. Compare each to the DSO the forecast ASSUMED for that counterparty, or to the single blended number
   if that is all the model carries.
3. Build a roll rate per top counterparty: current to 30, 30 to 60, 60 to 90, 90 to write off. A roll
   rate keeps the shape the average hides.
4. Measure dilution: credit memos, returns, allowances, discounts and bad debt write offs over gross
   billings for the last twelve months, as a percentage. Past the agreement's threshold it also cuts
   borrowing base availability.
5. State DSO excluding the largest customer, next to DSO including it.
</task>

<trap>One large counterparty paying early carries the blended DSO while the long tail deteriorates
underneath it. "DSO improved to 41 days" is then true and misleading at the same time. The weighted
average hides the distribution, which is the only thing that tells you whether collections are
actually healthier.</trap>

<stop>
If collections came in light for three consecutive months, do NOT call it bias. Over thirteen weeks,
seasonality and bias are indistinguishable. Compare the same weeks last year and the trailing twelve
month pattern first. If you do not have that history, say the sample is too short to separate them and
say so in those words rather than declaring a trend.
</stop>

<output_format>Exhibit C: counterparty | TTM billings | DSO assumed | DSO realised | difference in
days | roll rate current/30/60/90 | dilution % | AR over 90 days. Then the blended DSO with and
without the largest customer.</output_format>

<role>Controller who knows where the money actually goes. Claude Opus 5.5.</role>

<task>
1. Attribute every historical disbursement in the last thirteen weeks to exactly one modelled
   category. Unattributed spend is its own reported line and must sit under {{MATERIALITY}}.
2. Open POs not yet invoiced: pull the open PO report with expected receipt dates and payment terms.
   This is the most common missing outflow in a forecast built from the AP aging alone.
3. Held cheque listing. Cheques written and not released are a disbursement the analyst has already
   decided to make.
4. Test the vendor stretch, if the forecast assumes one. Model the stretch AND its consequence in the
   SAME week: past sixty days it can reduce borrowing base availability under the agreement's own
   definitions, and it can trip supplier credit holds that break the receipt side of the same forecast.
5. Name which vendors are on credit hold terms and what the stop ship trigger is.
</task>

<trap>Paying vendors late is modelled as free liquidity. It is not. Under many agreements AP past
sixty days reduces availability, and the lender sees the AP aging weekly anyway, so the stretch is
visible to them in the same week it helps you. A stretch modelled without its availability
consequence makes week 7 look survivable when it is not.</trap>

<stop>If the open PO report is not available, do not model disbursements from the AP aging alone and
call it complete. Mark the committed but not invoiced line NOT TESTED, name the report, and state the
direction of the resulting understatement.</stop>

<output_format>By week and category: AP by due date | open POs | held cheques | payroll | payroll
taxes | sales tax and VAT | debt service | other, each with its source id. Then the attribution table
for the last thirteen weeks with the unattributed line.</output_format>

<role>Claude Opus 5.5. Read the agreement. Assume nothing.</role>

<task>
1. Read the credit agreement's DEFINITION of the covenant, clause by clause, and bridge from the P&L's
   EBITDA to covenant EBITDA with one row per clause. They will differ. Typical divergences worth
   checking: income taxes added back whether paid, payable or accrued; non cash charges added back but
   asset write downs specifically NOT; gains on sales of real estate, equipment, discontinued
   operations and debt forgiveness SUBTRACTED; named capped add backs.
2. Rebuild the covenant's own denominator from its definition, not from the certificate.
3. Re derive the ratio for the last two test dates and reconcile to the filed compliance certificate.
   A difference you cannot bridge clause by clause is a finding, not a rounding.
4. Build the trailing twelve month roll forward for the next four test dates: what rolls OFF the back
   of the window, what rolls ON, and the implied ratio at each.
5. Map the thirteen weeks onto those test dates and state the FIRST breach date.
6. Rebuild availability for all thirteen weeks: borrowing base after ineligibles and reserves, less
   the availability block, less loans outstanding, less letters of credit. Liquidity is unrestricted
   cash plus excess availability. Never cash plus unused commitment.
</task>

<trap>Current headroom tells you almost nothing. The covenant is tested trailing twelve months at a
period end while the forecast is weekly, so a strong quarter rolls OFF the back of the window as a new
one rolls on. A company can sit comfortably above the ratio all quarter and breach at the test date
purely because of what dropped out. The roll forward is the answer, not the headroom.</trap>

<stop>
If the credit agreement or the last compliance certificate is absent, produce the availability
schedule and STOP before any ratio. Name both documents. Every covenant convention is agreement
specific, and a ratio computed from a textbook definition is a number you cannot defend to the lender
who wrote the actual one.
</stop>

<output_format>Exhibit D: test date | TTM EBITDA rolling off | rolling on | covenant EBITDA | fixed
charges or denominator | ratio | covenant level | headroom | PASS or BREACH. Then the P&L to covenant
EBITDA bridge, one row per clause with the clause reference. Then the first breach date.</output_format>

<role>Claude Opus 5.5.</role>

<task>For the first breach date from prompt 07, state the specific conditions that avoid it, each as a
testable statement with a number and a date, ranked by how much control the company actually has.
Examples of the SHAPE required: "collections from the top five counterparties run at 38 days rather
than the realised 47, from week 3, worth X". Not "improve collections".

For each condition state: the dollar effect on the ratio, who owns it, the date by which it must be
true, and what evidence would show it is happening or not by then.</task>

<trap>The comfortable list is the one full of things the company does not control: a customer paying
early, a delayed capex approval, a sale closing. Rank by control. A plan resting on three
uncontrollable items is not a plan, and the lender conversation goes better if you say which items
those are before they ask.</trap>

<stop>Do not state a condition you cannot attach a number and a date to. A qualitative condition is a
hope, and it reads as one in a lender meeting.</stop>

<output_format>Condition | ratio effect | owner | true by date | evidence it is happening | control
(high, medium, low). Sorted by control descending.</output_format>

<role>Independent reviewer. Claude Opus 5.5. Return CLEAR or HELD. HELD blocks prompts 10, 11 and 12.</role>

<task>
Re derive independently:
1. Week 0 opening cash per account equals the bank statement closing available balance to the cent,
   with every reconciling item itemised and no plug. This one is binary.
2. Closing cash of week N equals opening cash of week N+1, for all thirteen weeks.
3. Restricted balances are excluded from liquidity and disclosed separately.
4. The back test graded receipts and disbursements separately and gross, and reports mean absolute
   error alongside mean error.
5. No OFFSETTING BIAS flag is unexplained.
6. The covenant bridge reconciles to the last filed compliance certificate clause by clause, or the
   difference is named as a finding.
7. Every figure carries a tier and a source id. Count the cells reading NOT TESTED and state it as a
   fraction.
8. The rebuild was completed and written down BEFORE the analyst's file was opened.
</task>

<trap>A forecast that matched actuals last month is not a validated forecast. A receipt landing late
and a payment landing late cancel, the net looks perfect, and both lines were wrong. Treat a clean net
over two broken lines as a FAIL, not a reconciliation. The same logic applies to your own rebuild: a
rebuild that ties on totals can still be wrong on classification, with an intercompany transfer
counted as a receipt and a revolver draw counted as operating cash.</trap>

<stop>
HELD names the failing item, the arithmetic, the source ids, and the ONE thing that unblocks it: a
named human resolving it, or a named document arriving. It also fires, automatically, if the analyst
and the reviewer are the same person. That is not a review, and no amount of care makes it one.
Produce nothing downstream on HELD.
</stop>

<output_format>CLEAR or HELD, the eight checks with PASS or FAIL and numbers, and on HELD the
unblocking item.</output_format>

<role>Claude Opus 5.5. Runs only on CLEAR, and only after prompts 03 to 09 are written down.</role>

<task>Open the analyst's workbook for the first time. Reconcile your independent rebuild to it, BY
CATEGORY, never in total. For each difference: the amount, the week, which version is right, the
evidence, and whether it changes the covenant conclusion.</task>

<trap>A rebuild that ties to the analyst's file in total can be wrong in every category: an
intercompany transfer counted as a receipt, a revolver draw counted as operating cash, a refund netted
against a disbursement. The thirteen week total is then right and every operating line is wrong, which
is the shape that survives review and fails at the bank.</trap>

<stop>If a difference exceeds {{MATERIALITY}} and you cannot determine which version is right from the
source documents, do not pick. Name the document that settles it and leave the item open.</stop>

<output_format>Exhibit E: category | week | rebuild | analyst file | difference | which is right |
evidence | covenant impact Y/N. Then the three largest differences written out.</output_format>

<role>Claude Opus 5.5. Runs only on CLEAR.</role>

<task>One page. In this order: what was rebuilt independently and from which exports; the three largest
differences to the analyst's file and which is right; the bias findings with direction and magnitude
PER LINE; the first breach date and the condition that avoids it; what could not be checked and why;
and every STOP condition that fired during the run.</task>

<trap>A memo that leads with the headline accuracy percentage has already lost the argument, because
that number is the one statistic the offsetting error hides behind. Lead with the per line bias. The
lender's question is never whether you are accurate, it is whether you know which direction you are
wrong in and by how much.</trap>

<stop>Do not write the memo with any NOT TESTED cell inside a figure it cites. Either test it or say in
the memo that it was not tested and why.</stop>

<output_format>The memo, one page, then the sign off block: prepared by, reviewed by, date.</output_format>

<role>Claude Opus 5.5.</role>

<task>Produce the sign off sheet: every figure going to the lender, its source id, its tier, and the
named person who owns it. State plainly that a named human signs, that the model signs nothing, and
that this pack supports the certificate rather than being it.</task>

<trap>The most dangerous output of any review is a clean result nobody owns. An unsigned clean memo
gets forwarded, quoted, and treated as verified by people who never saw the STOP conditions that
fired.</trap>

<stop>If any figure has no named owner, do not produce the sheet. List the unowned figures.</stop>

<output_format>Figure | value | source id | tier | owner. Then the sign off block.</output_format>

<role>Data engineer seat. Claude Sonnet 5 is acceptable, this is mechanical file generation. Run in
Claude Code at {{PROJECT_DIR}}. If you review one month in chat, stop at prompt 12.</role>

<task>
Create this tree. Write every file with real content. Print ls -R, then run pytest --collect-only -q.

  {{PROJECT_DIR}}/
    README.md                 what it does, the run order, the pass condition
    requirements.txt          the pinned lines below
    config/assumptions.yaml   week convention, fiscal calendar, materiality, tolerances. Read, never
                              derived in code
    data/raw/                 source exports land here. NO module ever writes to this directory
    data/normalised/          parquet, every row carrying source_id and an ingest timestamp
    forecasts/filed/          every submitted forecast, versioned immutably by submission date.
                              Without this the back test in prompt 04 is impossible
    ingest/bank.py            statements to transactions, available balance per account, restricted flag
    ingest/agings.py          AR by invoice, AP by vendor, open POs
    ingest/ledger.py          GL detail. De duplicate on journal id + line + timestamp + amount and
                              REPORT the count and value removed. A silent de dup falsifies the rebuild
    core/calendar.py          week boundaries, payroll dates, tax dates, debt service dates
    core/tieout.py            week 0 opening cash against the bank. The milestone
    rebuild/collections.py    per invoice expected pay date from per counterparty roll rates
    rebuild/disbursements.py  AP + open POs + payroll + taxes + debt service
    rebuild/assemble.py       the thirteen weeks, with the circular interest solver
    backtest/grade.py         per line mean error and mean absolute error, offsetting bias detector
    covenant/engine.py        TTM roll forward, availability, headroom, first breach date
    report/exhibits.py        Exhibits A to F
    tests/                    one test file per module

requirements.txt, all real packages, verify each on PyPI before pinning:
  pandas            weekly bucketing and joins
  duckdb            query multi million line GL exports without loading them
  python-dateutil   rrule generates biweekly pay dates and the 15th of month deposit series exactly
  openpyxl          read the analyst workbook, write the exhibit workbook
  pyyaml            config/assumptions.yaml
  pytest            the test runner

Read before you trust a default: python-dateutil rrule at
https://dateutil.readthedocs.io/en/stable/ and duckdb's Python client at
https://duckdb.org/docs/stable/clients/python/overview
</task>

<trap>Independence has to be enforced by the code, not by intention. The module that reads the
analyst's workbook must not be importable until stages 1 to 7 have completed and written to disk.
Make that an explicit precondition that raises. A reviewer who can peek will peek.</trap>

<stop>If a package name above does not resolve on PyPI, stop and name it. Do not substitute a similar
package and do not invent a version.</stop>

<output_format>ls -R, then the pytest collection output.</output_format>

<role>Engineer who writes the check before the code. Claude Opus 5.5.</role>

<task>
For calendar, bank ingest, ledger ingest, tieout and grade, in that order: write the failing test
FIRST, run pytest and show it failing for the right reason, then implement, then show it passing.

The tests that must exist, because these are the failures that actually happen here:
  calendar   for a known year the biweekly generator produces 26 pay dates, and the quarter carrying
             7 is identified by name
  calendar   a 4-4-5 fiscal year with 53 weeks does not break code that assumed 52
  calendar   W-FRI and W-SUN produce different week labels for the same data, and the convention comes
             from config, never from a default
  bank       a posting timestamp in UTC buckets to the entity's LOCAL week, and no transaction's local
             date differs from its exported date by more than one day
  bank       inflow positive and outflow negative is asserted per source file, with a fixture
             containing a credit memo, a vendor refund and a reversing journal
  ledger     duplicate journal lines are removed AND the count and value removed are reported
  ledger     every row carries a transaction currency, and conversion uses a dated rate table
  tieout     rebuilt opening cash equals the statement closing available balance to the CENT, with
             outstanding cheques and deposits in transit itemised and no residual plug
  grade      the forecast graded for a week is the as filed version made BEFORE that week
  grade      mean absolute error far exceeding absolute mean error raises the offsetting bias flag
  assemble   non convergence of the interest solver fails loudly, it does not return the last iterate
  join       customer matching joins on customer ID, never on name, and affiliates group together
</task>

<trap>An in sample back test always looks excellent, because the model is being graded on the weeks it
was fitted to. Use rolling origin, walk forward. The only way that is possible is if the as filed
forecasts were versioned at submission, which is why forecasts/filed/ exists in prompt 13. If the
history was overwritten, no amount of code recovers it.</trap>

<stop>If a test passes on its first run before the implementation exists, the test is wrong. Say so and
rewrite it.</stop>

<output_format>Per module: the failing run, the implementation, the passing run.</output_format>

<role>Claude Opus 5.5. This is the milestone. There is no partial.</role>

<task>
Run the tie out for {{AS_OF}}.

PASS: for EVERY bank account, rebuilt opening cash equals the statement's closing available balance to
the cent, with outstanding cheques and deposits in transit itemised individually from the bank
reconciliation, and no residual plug line. Print the per account table.

FAIL: print the per account difference and a line level list of unmatched items, then exit non zero.
Nothing downstream runs. Do not annotate a FAIL and continue.

It runs first because a wrong opening balance shifts all thirteen weeks by the same amount, silently,
and every later check still passes.
</task>

<trap>A tie that passes only after a plug line has not passed. If your reconciliation carries a line
called "other" or "unreconciled", the number is unproven and the plug is hiding a classification
error somewhere upstream. Itemise or fail.</trap>

<stop>If any account has no statement for {{AS_OF}}, do not run. Print the account and the statement to
request. Do not begin the rebuild from a GL cash balance.</stop>

<output_format>Per account: rebuilt opening | statement closing available | outstanding cheques |
deposits in transit | difference | PASS or FAIL. Then the exit code.</output_format>

<role>Claude Opus 5.5.</role>

<task>
| Symptom | Cause | Fix |
|---|---|---|
| Rebuild and analyst file differ by about a week on every line, totals match | week convention drift, W-FRI against W-SUN | pin the convention from config, store week_start and week_end as real dates on every row, never label a week by number alone |
| Receipts land in the wrong week, mostly at month ends | UTC posting timestamps bucketed as local dates | normalise to the entity's local date before any weekly bucketing |
| A persistent one to two day early bias on receipts that no assumption removes | grading posting date against value date | pick one date field and use it on both sides. Bank value date is what settles |
| One "month" has five weeks and rent lands twice | 4-4-5 calendar derived in code instead of read from config | read the fiscal calendar from config. A 53 week year breaks anything assuming 52 |
| Disbursements net against receipts | sign convention not normalised at ingest | one convention at ingest, asserted per source file |
| Tie out fails by an exact multiple of one transaction | duplicate journal lines | de duplicate on the composite key AND report what was removed |
| Eligible AR is overstated | foreign currency translated at one spot rate, or non Dollar accounts are ineligible outright | dated rate table, and check the agreement separately on eligibility, which is a different question from translation |
| Concentration comes out wrong | joined on customer name, so ACME Corp and Acme Corporation are two customers | join on customer ID, and group affiliates, because the agreement's tests usually apply to the debtor or its affiliates |
| The back test looks excellent | in sample, or the model quietly converged on the analyst's file | rolling origin on versioned as filed forecasts, and the analyst module stays unimportable until stage 7 completes |
| Interest never settles | the circular solver diverges | fail loudly on non convergence with the iteration count, never return the last iterate |

DEFINITION OF DONE. One command runs the month, prompt 15 exits zero, the back test runs on versioned
as filed forecasts, every exhibit cell carries a source id or reads NOT TESTED, and a re run produces a
byte identical workbook. A run that is not reproducible is not evidence.

WHAT TO BUILD NEXT, in order:
1. The borrowing base engine, so availability is rebuilt rather than taken from the certificate.
2. The covenant roll forward for the next four test dates, which is the same ingest with different
   arithmetic.
3. Automatic versioning of each submitted forecast at the moment it is sent, so the back test never
   depends on anyone remembering.
</task>

<trap>The tempting next build is a prettier chart of the thirteen weeks. The chart shows the forecast,
and the forecast was never the problem. The bias table is the product.</trap>

<stop>If your symptom is not in the table, do not guess. Print the full traceback and the first 20 rows
of the offending file, and work from evidence.</stop>

<output_format>The symptom matched, the fix applied, the re run result.</output_format>