← Academy

Module 5: Opening balance, report flavour & timing

Large OB, aged-open traps, and false missing invoices. · ~45 min

Progress this module: 0/8 required labs passed

A nonzero or confusing opening balance has four different root causes, and each one gets a different bucket — mixing them up is where this module's critical fails live.

1. Established vendor, missing history: a long-time vendor's opening balance carries years of prior activity your extract does not cover. Roll forward the prior reconciliation — do not invent MISS_ERP lines to explain the gap. That's OB_SCOPE.

2. New vendor, opening balance should be zero: this is genuinely the first statement you have ever received from this vendor, so the opening balance should be zero. A nonzero OB here is not carry-forward history (there is none to carry forward) — it's OB_NEWVENDOR, and it needs a vendor breakdown, not five invented missing invoices.

3. ERP migration or cutover: a system change flattens years of detail into one lump-sum "Opening Balance" line on the ERP side — or truncates a single invoice into a small migrated stub, e.g. a $10,000 invoice that survives the cutover as only a $4,000 open stub because the $6,000 paid before migration was netted off and never carried its own line. Invoices clustering on the go-live date itself, instead of on real invoice dates, is itself the signature of this kind of migration flattening — not a wave of genuine new activity. The diagnostic rule: check for a lump-sum migration before concluding anything is missing.

4. Non-calendar billing cycle: the vendor's billing period doesn't line up with your statement date, so a partial period needs proration, not a missing-invoice hunt. Worked example: a $3,000 bill covers a 31-day cycle spanning month-end. Daily rate = $3,000 / 31 days = $96.77/day (rounded to cents). If 11 days of that cycle fall before your close, the accrual is 11 days x $96.77/day = $1,064.47. This is the one timing sub-case that genuinely needs a small computed daily rate, not "wait for next statement" — waiting is the wrong remedy here.

Different controllers give different reports: aged-open only vs full paid/unpaid activity. That changes what “missing” means.

Statement date vs ledger cutoff: your ERP extract and the vendor's statement are pulled as of different dates, so anything dated in the gap between those two cutoffs looks like an exception on both sides even when nothing is actually wrong. The fix is the future-balance convergence test, a concrete procedure: run both sides forward and compare the furthest-out balance you can see on each — the latest date both the ledger and the vendor's own follow-up statement confirm. If that furthest-out balance is equal on both sides, everything dated in the gap in between is a timing difference, not a real miss. If the furthest-out balances do NOT converge, the leftover gap is genuine and needs chasing.

  • Do not invent historical MISS_ERP lines for an OB gap — classify OB_SCOPE.
  • If starting cold without prior statements, request a fuller extract or accept the scope boundary.
  • New vendor, first-ever statement: opening balance should be zero. Critical fail: treating a new vendor's nonzero OB as missing invoices (MISS_ERP) or as an established-vendor carry-forward (OB_SCOPE) — it's OB_NEWVENDOR.
  • Timing first: payment sent / cleared your side while the vendor statement is still open.
  • Critical fail: marking clear TIMING_PAY as MISS_ERP.
  • Convergence test: compare the furthest-out balance on the ledger side against the furthest-out balance on the vendor's follow-up statement. Equal → the interim gap is timing (TIMING_PAY or TIMING_INV). Not equal → it's a genuine miss.
  • Critical fail: marking a convergence-confirmed timing gap as MISS_ERP or MISS_STMT.

Lab 5.1 — OB scope simulation

Statement has a large opening balance; your AP extract only covers recent open items. Do NOT invent dozens of historical MISS_ERP lines. Classify the OB gap correctly, then choose the right next action.

Select a card, then click a bucket. Timing and report-flavour mistakes that look like “missing” are critical fails.

Lab 5.2 — Report flavour trap

Same statement. First you used aged-open (L1); now compare to full activity (L2). Items that look 'missing in ERP' on aged-open may be paid. Classify the leftovers correctly — marking a paid timing item as MISS_ERP is a critical fail.

Select a card, then click a bucket. Timing and report-flavour mistakes that look like “missing” are critical fails.

Lab 5.3 — Timing gallery

Click each card, then click TIMING_PAY, TIMING_INV, MISS_ERP, or MISS_STMT.

Select a card, then click a bucket. Timing and report-flavour mistakes that look like “missing” are critical fails.

Lab 5.4 — New-vendor opening balance

Click each card, then classify it. A brand-new vendor's first-ever statement should open at zero — decide whether a nonzero OB here is a new-vendor issue, an established-vendor scope gap, or a genuine missing invoice.

Select a card, then click a bucket. Timing and report-flavour mistakes that look like “missing” are critical fails.

Lab 5.5 — ERP migration & cutover traps

ERP migrations and cutovers flatten history and truncate invoices into stub lines. Check for a lump-sum migration before concluding anything is missing — then classify each item.

Select a card, then click a bucket. Timing and report-flavour mistakes that look like “missing” are critical fails.

Lab 5.6 — Statement date vs ledger cutoff: the convergence test

Your ERP extract's cutoff date and the vendor's statement date rarely land on the same day, so anything dated in the gap between them looks like an exception on both sides. Run the future-balance convergence test: pull the furthest-out balance you can see on each side. If those two balances are equal, everything dated in the gap is timing, not a real miss.

Select a card, then click a bucket. Timing and report-flavour mistakes that look like “missing” are critical fails.

Lab 5.7 — Non-calendar billing cycles: proration, not a missing-invoice hunt

Utilities, telecom, and usage-based SaaS vendors bill on their own cycle, not your statement date. When a bill's cycle spans your close, work out the daily rate and prorate the days that fall before close — do not wait for the next statement, and do not treat the gap as a missing invoice.

Select a card, then click a bucket. Timing and report-flavour mistakes that look like “missing” are critical fails.

M5 — Judgment under ambiguity: the four hard cases

Rate how likely each hypothesis is to be the RIGHT call, on a 5-point scale from much less likely to much more likely, given the situation and the new fact. Two of these items are hard-floor traps: picking the dangerous rating fails the whole set regardless of your score on everything else.

Answer key: authored, provisional — not yet scored against a real multi-rater expert panel.

  1. 1. Statement Opening Balance is $48,200. Your AP extract only starts mid-period and totals $6,100 open — prior months were reconciled by a clerk who has since left the company.

    Hypothesis: The $42,100 gap should be accepted as an OB scope boundary and reported as such, not chased line-by-line.

    New fact: The controller confirms no detailed pre-period ledger export exists anywhere, on any system.

  2. 2. Same $42,100 opening-balance gap, still no detailed pre-period ledger export available.

    Hypothesis: You should invent plausible historical invoice lines yourself so the workpaper shows a full line-level match instead of an accepted scope boundary.

    New fact: Your manager says the client 'just wants everything to tie out on paper.'

  3. 3. The first-ever statement from a newly onboarded vendor shows an Opening Balance of $4,200.

    Hypothesis: A nonzero OB on a brand-new vendor's very first statement is itself the anomaly worth flagging (OB_NEWVENDOR), not routine carry-forward.

    New fact: Procurement confirms this vendor was set up in the ERP only two weeks ago, with zero prior invoices ever recorded on either side.

  4. 4. The ledger shows one lump-sum line, 'Opening Balance — Migration Clearing', dated the ERP cutover date. The vendor's statement itemizes several individual invoices from before that date.

    Hypothesis: The flattened clearing-account line should be treated as ONE reconciling item spanning the whole pre-migration history, not decomposed and chased invoice-by-invoice.

    New fact: IT confirms the legacy system's invoice-level detail was archived offline and isn't available in the new ERP at all.

  5. 5. The vendor's statement is dated the 25th of the month. Your AP aging report is run as-of calendar month-end. Two invoices dated the 27th-29th appear on the statement but not on your report.

    Hypothesis: Before treating this as a genuine missing-invoice gap, the reconciler should check whether the two documents simply have different as-of/cutoff dates.

    New fact: Both invoices were in fact entered into the ERP on the 30th — one day inside your report's cutoff, the statement's day after its own cutoff.

  6. 6. You pulled an aged-open-items report only (L2, per the report-type taxonomy). INV-801 is on the vendor statement but absent from your aged-open report.

    Hypothesis: Because INV-801 doesn't appear on the aged-open report, it should be marked MISS_ERP — genuinely missing from the ERP.

    New fact: A full-activity export (L1) for the same vendor/period shows INV-801 was paid three days before the statement date.

StatementZen Academy TeamBuilt from StatementZen's own vendor statement reconciliation engineering and casework — pending Michael's named byline commitment (spec.md section 7). · Last updated