Schedules, accruals & roll-forwards

The supporting evidence layer. Every balance sheet account needs a schedule behind it, and the schedule must tie.

This is the most under-served area in accounting software UI — most products have a general ledger and statements, and then the schedules live in spreadsheets. That handoff is where closes break.

1. The universal roll-forward

Every schedule in accounting has the same shape. Encode it once.

  Opening balance                     84,220.00      ← must equal prior period closing
  + Additions                         22,400.00
  − Releases / amortization          (18,900.00)
  ± Adjustments                          (500.00)
  ─────────────────────────────────────────────
  Closing balance                     87,220.00
  ═════════════════════════════════════════════
  GL balance at 30 Sep 2026           87,220.00
  Difference                               0.00   ✓ Tied

RollForward is one component with a configurable column set. Prepaids, accruals, deferred revenue, fixed assets, intangibles, leases, equity, allowances, and inventory reserves are all this shape.

Non-negotiable rules:

1. Opening must equal the prior period's closing. Asserted, not assumed. A break here means someone edited history.
2. The closing balance must tie to the GL. The tie is displayed as part of the component, not computed elsewhere.
3. The difference line is always visible. It is the number the user is working to zero.
4. A non-zero difference is the primary state of the screen, with the amount, an "Investigate" action, and a required explanation field.
5. Every movement traces to journal entries. Clicking Additions 22,400.00 drills to the entries that make it up, and they sum to the line.

2. Prepaid expenses

Cash paid now, expense recognized over time.

type PrepaidItem = {
  vendor: string;
  description: string;
  invoiceRef: string;
  totalAmount: Money;
  serviceStart: Date;
  serviceEnd: Date;
  method: "straight-line" | "usage" | "manual";
  monthlyAmortization: Money;      // derived for straight-line
  amortizedToDate: Money;
  remaining: Money;                // totalAmount − amortizedToDate
  glAccount: string;               // the expense account it releases to
};

UI rules:

• Partial first and last months are prorated by day, not treated as whole months. A policy starting 18 Sep amortizes 13/30 of a month in September. Straight-line-by-month is a simplification that produces a stub at the end, and the component makes the convention explicit rather than silent.
• remaining is the balance sheet number. The schedule total must equal the prepaid GL account.
• Items fully amortized in the period are shown, then dropped. Silently disappearing rows make the roll-forward impossible to follow.
• A prepaid with a service end date in the past and a non-zero balance is an exception, flagged prominently. It usually means an amortization entry was missed.

3. Accrued liabilities

Expense incurred, invoice not received.

The auto-reversal rule is the whole component. An accrual that doesn't reverse double-counts the expense when the real invoice arrives and is coded to expense. Coding the invoice against the accrued liability also works, but depends on someone remembering; auto-reversal removes that dependency.

  Sep accrual:    Dr Professional fees 12,000 / Cr Accrued liabilities 12,000
  Oct 1 reversal: Dr Accrued liabilities 12,000 / Cr Professional fees (12,000)
  Oct invoice:    Dr Professional fees 11,400 / Cr Accounts payable 11,400
  Net Oct effect: (600) — the true-up, automatically

UI rules:

• AdjustingEntryForm defaults autoReverse: true for accruals and displays the reversal date inline: "Reverses 1 Oct 2026".
• The scheduled reversal is visible in the next period before it posts, so a reviewer sees it coming.
• Estimate vs. actual is tracked. The schedule shows what was accrued, what the actual turned out to be, and the true-up — this history is how accrual estimates get better, and it's what an auditor asks for.
• Accruals aging beyond two periods are flagged. A liability accrued three months running with no invoice is either a bad estimate or a missing vendor.

4. Deferred revenue (ASC 606 / IFRS 15)

Cash received or billed, revenue not yet earned. The mirror of prepaids, and the one with the most regulatory structure.

The five-step model, as it shows up in the UI:

1. Identify the contract
2. Identify the performance obligations — the unit of recognition
3. Determine the transaction price
4. Allocate the price to obligations — by standalone selling price
5. Recognize revenue as each obligation is satisfied

type PerformanceObligation = {
  contractId: string;
  description: string;              // "Platform subscription", "Implementation"
  allocatedPrice: Money;            // step 4 — uses largest-remainder allocation
  standaloneSellingPrice: Money;
  recognitionMethod: "ratable" | "point-in-time" | "input-measure" | "output-measure" | "usage"; // ASC 606 measures of progress
  serviceStart?: Date;
  serviceEnd?: Date;
  recognizedToDate: Money;
  deferredBalance: Money;
};

UI rules:

• Allocation across obligations uses largest-remainder so the allocated amounts sum exactly to the transaction price. Off-by-a-cent allocation is a real and common bug.
• Contract asset vs. contract liability are different balance sheet lines. Consideration received (or unconditionally due) ahead of delivery is a contract liability (deferred revenue). Revenue recognized before the right to payment is unconditional is a contract asset; recognized with an unconditional right but not yet invoiced is an unbilled receivable. Within a contract the position is presented net, as one asset or one liability (required); across contracts it is never netted, and the component prevents it.
• The revenue waterfall is a first-class view: how much of the current deferred balance recognizes in each future period. This is the number every SaaS board asks for.
• Variable consideration and constraints are flagged rather than modeled — the estimate is a judgment, and the UI's job is to make sure it's documented and reviewed, not to compute it.

5. Fixed assets & depreciation

type FixedAsset = {
  tag: string;
  description: string;
  category: string;                 // drives default life and method
  cost: Money;
  inServiceDate: Date;              // NOT the purchase date — depreciation starts here
  usefulLifeMonths: number;
  salvageValue: Money;
  method: "straight-line" | "declining-balance" | "sum-of-years" | "units-of-production";
  convention: "full-month" | "mid-month" | "half-year" | "mid-quarter";
  accumulatedDepreciation: Money;
  netBookValue: Money;              // cost − accumulated
  disposal?: { date: Date; proceeds: Money; gainLoss: Money };
};

UI rules:

• In-service date, not purchase date. An asset bought in March and installed in June depreciates from June. This distinction is a frequent source of error and the form labels it explicitly.
• The convention is visible. Half-year, mid-month and mid-quarter conventions change the first and last period's expense, and a user reconciling to a tax schedule needs to know which is in force.
• Book and tax depreciation are separate schedules. They use different lives and methods, and the difference creates a deferred tax item. The component supports parallel books and shows the difference.
• Disposal computes gain/loss and shows the working: Proceeds − NBV = Gain/(Loss). Removing an asset without recognizing gain or loss is a misstatement.
• A worked straight-line example. Equipment costing $48,000 with a $3,000 salvage value and a 60-month life depreciates (48,000 − 3,000) ÷ 60 = 750 a month. Sold after 26 months for $25,000: accumulated depreciation is 19,500, NBV is 28,500, and the disposal posts Dr Cash 25,000 / Dr Accumulated depreciation 19,500 / Dr Loss on disposal 3,500 / Cr Equipment 48,000.
• NBV must never go below salvage value. Asserted, and a schedule that would breach it is an error state.
• Fully depreciated assets still in service are shown, greyed. Their NBV equals salvage value (often zero) but they exist, and dropping them from the register loses the asset.

6. Intangibles and amortization

Same shape as fixed assets, with two differences the UI must reflect:

• Goodwill and indefinite-lived intangibles are not amortized — they are tested for impairment (US GAAP private companies may elect to amortize goodwill over up to ten years). The schedule shows them with no amortization row and an impairment test date.
• Impairment is a judgment event, recorded with its trigger, its measurement basis, and its approver. Goodwill impairment is the excess of a reporting unit's carrying amount over its fair value, capped at the goodwill (ASU 2017-04); a long-lived asset group is first tested for recoverability on undiscounted cash flows (ASC 360-10-35-17).
• Internal-use software is changing. ASU 2025-06 (ASC 350-40), effective for annual periods beginning after 15 December 2027, removes the preliminary / development / post-implementation stages: costs are capitalized once management has authorized and committed funding and it is probable the project will be completed and used as intended, with significant development uncertainty resolved first. A capitalization schedule should therefore record the date the threshold was met, not a stage.

7. Leases (ASC 842 / IFRS 16)

Both frameworks put nearly all leases on the balance sheet: a right-of-use asset and a lease liability.

  Lease liability = PV of lease payments not yet paid, at the discount rate
  ROU asset       = Lease liability + prepaid lease payments + initial direct costs − lease incentives received

UI rules:

• The discount rate is displayed and its source stated — implicit rate if determinable, otherwise incremental borrowing rate; an entity that is not a public business entity may elect a risk-free rate by class of asset (ASU 2021-09). It drives every number in the schedule and it's a judgment.
• Short-term leases may stay off the balance sheet. A lease of twelve months or less with no purchase option reasonably certain to be exercised can be expensed straight-line by policy election (ASC 842-20-25-2); the schedule records the election rather than an empty ROU line.
• Under ASC 842, operating vs. finance classification changes the P&L and the balance sheet presentation. Operating leases produce a single straight-line lease expense; finance leases split into amortization and interest; the two are presented as separate lines or disclosed. IFRS 16 has no lessee classification — every lease is depreciation plus interest. The component renders both correctly and labels which.
• The ROU asset and the lease liability amortize on different curves and diverge over the lease term. Showing them as one schedule is wrong; ScheduleTable renders parallel columns.
• Modifications and remeasurements are events, recorded with dates and reasons, that produce a new schedule from that point — never a silent edit of the original.
• The maturity analysis (undiscounted payments by year, reconciled to the discounted liability) is a required disclosure and a first-class view.

8. Allowances and provisions

Valuation allowances against assets (credit losses, inventory obsolescence) and estimated liabilities (warranty, refund liabilities for expected returns).

UI rules:

• The methodology is displayed, not just the number. "Allowance = 1% of current + 4% of 1-30 + 10% of 31-60 + 35% of 61-90 + 100% of 90+, adjusted for current conditions and forecasts" — with the calculation shown and each input traceable to the aging.
• The true-up is visible. Opening allowance → provision expense → write-offs → recoveries → closing allowance. A roll-forward like everything else.
• A write-off is not a provision. Writing off a specific receivable reduces both AR and the allowance with no P&L impact; increasing the provision hits the P&L. Conflating them is a classic error and the UI names each action distinctly.
• CECL / expected-credit-loss models (ASC 326-20) are supported as an input to the methodology, not modeled by the component. Lifetime losses are booked from day one — a current invoice carries an allowance too. ASU 2025-05, effective for annual periods beginning after 15 December 2025, lets any entity assume current conditions at the balance sheet date persist for current AR and contract assets, and lets entities that are not public business entities also consider collections received after the balance sheet date; the component records which election is in force and the collection cut-off date used. The judgment belongs to the accountant; the UI's job is to record it and show the working.

9. Recurring and schedule-generated entries

Entries a schedule produces automatically each period: amortization, depreciation, revenue recognition, straight-line lease expense.

UI rules:

• They are source: "system" and read-only. A wrong output means a wrong schedule; the UI routes the user to the schedule, not to the entry.
• They are previewable before posting. A close should never be surprised by what the schedules generated — SchedulePreview shows the full set of entries the period will produce, with totals, before anything posts.
• A schedule that fails to generate is a blocking close exception, surfaced in the close checklist, not a silent absence.
• Posting is a batch with one audit record, not N unrelated entries. Reversing a batch reverses all of it.

10. The schedule inventory

Every balance sheet account maps to exactly one supporting schedule type. This mapping is the backbone of AccountTieOut, and an account with no mapping is itself a finding.