Change One Policy and Every Dependent Schedule Has to Move

A policy change is a change to every schedule that depends on it

One accounting policy change moves inventory, cost of sales, tax, retained earnings and cash in the same period. The test is whether they move again when the assumption changes twice. A driver-based model cannot run it: its ratios re-impose the answer.

Changing one accounting policy is never a one-cell edit. It moves every schedule that references the affected balance, and it moves them in the same period: cost of sales, inventory, tax, retained earnings and cash all respond to a change in how inventory is measured.

That propagation is the point of the test. A model that links schedules will move all of them together when the policy changes. A model that was built by patching will move the ones someone remembered to patch, and the difference between the two is one of the clearest signals of how a workbook was put together.

The three policies below cover the cases a three-statement model usually meets. For each, the question is the same: what has to move, and what does it look like when only part of it moved.

Inventory method: what moves

A switch between inventory costing methods moves cost of sales, closing inventory and the tax charge in the same period.

Under IAS 2, inventories are measured at the lower of cost and net realizable value, and the cost formula is specific identification, FIFO or weighted average. LIFO is not permitted. Switching between FIFO and weighted average does not change the number of units; it changes the cost attached to the units sold and the cost attached to the units still held. If prices rose during the period, FIFO leaves more cost in closing inventory and reports a lower cost of sales than weighted average.

Four things have to move together:

If any of the four is unchanged while the others move, the model has a patch in it. A tax charge that stays flat while cost of sales moves is the usual tell: someone changed the inventory line and forgot that the tax is computed from profit, not typed next to it.

Depreciation method and useful life: what moves

A change in depreciation method moves the depreciation charge, accumulated depreciation, net book value and deferred tax together.

The sequence is the same shape as the inventory case, with one addition: a change in method or life is normally applied prospectively, so the model needs an opening net book value and a remaining life to recompute from. A model that depreciates a fixed percentage of opening net PPE, which is what the workbook in this series does at 10.49%, can accept a new rate but cannot represent the transition. It has no vintage schedule and no accumulated depreciation column.

The distinction is worth stating plainly rather than treating as a limitation to work around: a percentage-of-opening-balance model is a net-basis model. Such a model answers "what if the charge rate changes", not "what if we switch from reducing balance (declining balance) to straight line on the existing asset base", because the existing asset base does not exist in the workbook as a set of vintages.

Lease treatment: what moves

Reclassifying a lease moves the balance-sheet presentation, the interest charge and the operating cash-flow line at once.

Bringing an operating lease onto the balance sheet adds a right-of-use asset and a lease liability, splits the former rent line into depreciation and interest, and moves the cash outflow from operating activities to financing. Five lines move, in three statements, and none of them can move correctly without a lease schedule that carries the payment profile.

A model with no lease schedule cannot perform this change at all. It can only be told the answer. The three-statement workbook states this explicitly: no leases are modeled, and the debt is a single facility with no covenants, no margin ratchet and no arrangement fees. A reviewer asking "what happens if we capitalize the leases" is asking a question the model has no structure to answer, and the useful response is to say so rather than to produce a number.

Automatic linkage versus a hand-patched number

The difference between a linked model and a patched one is whether the number moves again when the assumption changes a second time.

That is the test: change the policy, note what moved, then change it back and change it to a third setting. A linked model returns to its original values exactly and moves to a new consistent set for the third setting. A patched model drifts. The first change moved the patched cells, the second moved the linked ones, and the third setting produces a mix of both.

Run it and record the answer, because the recorded answer is itself the audit evidence. Mica applies a change across every dependent schedule in one pass and marks each edited cell, so which numbers moved is answerable afterwards. Without the marking, the same test still works but the evidence has to be reconstructed by comparing saved copies.

The tax question, which is where most policy tests stop

Every policy change above moves pre-tax profit, and every one of them therefore moves tax. Whether the tax moves in the same period or later depends on a schedule most models do not have.

In the simplest case, a flat 25% of accounting profit, the tax charge follows profit before tax one for one, and a change in inventory method moves the charge in the same period. That is the case in the workbook behind this series, and it is stated as a limit: no deferred tax, no carried-forward losses, no capital allowances (tax depreciation) separate from book depreciation, no permanent differences.

The moment any of those exist, a policy change creates a timing difference, and the model needs a deferred tax balance to carry it. A change in depreciation method is the clearest example: the accounting charge moves immediately, the tax charge does not, and the gap accumulates as a deferred tax liability or asset. A model with no such balance will still balance. It simply puts the difference somewhere else, usually in cash or retained earnings, and neither is right.

So the policy-change test has a prerequisite worth checking first: does the model have a tax schedule, or does it have a tax rate? If it has a rate, the test measures the rate. If it has a schedule, the test can measure the policy.

What a Policy-Change Test Should Document

Run the change, record what moved, change it back, and record what returned. The record is the deliverable, and it is worth more than the answer.

For each policy change, the record should show: the cell that was changed, the cells that moved as a consequence, the cells that did not move and should have, and the date. That last row usually finds the bug. A list of what did not move is much shorter than a list of what did, and much easier to read.

Where the model has a check sheet, the same run re-executes the checks automatically, and any policy change that breaks a roll-forward will show up as a failing row before anyone reads the difference. That is the connection between this test and the twelve ties: the ties tell you the model is still coherent after the change, and the change tells you whether the coherence was linkage or luck.

Why a Driver-Based Model Cannot Answer a Policy Question

A driver-based model re-imposes its own ratios, so a policy change cannot move the balance it is meant to affect.

There is a version of this test that a driver-based model cannot pass, and it is worth being direct about it, because it is the version most models face.

Take the 40% gross margin and the 75-day inventory assumption in the workbook behind this series. Inventory is 75 days of cost of sales, and cost of sales is 60% of revenue. The inventory balance is therefore fully determined by revenue and two ratios. Now change the inventory costing method. The model has no cost-flow layer for the change to act on, so the days assumption simply re-imposes the same answer. The balance does not move, because the driver determines it.

What that means is not that the model is wrong. A days-based model is the right tool for "what does this business need if it keeps behaving like this", and it is the reason the forecast could be built from two statements with no assumptions supplied. But it is a model of ratios, not of accounting policies. Policy changes exercise a layer the model does not have.

So there are two honest positions:

The workbook states this in its own limits sheet, in three separate entries, and that is the right place for it. What the model does cover, in full, is set out in the three-statement hub. A model that advertises the questions it cannot answer is more useful than one that appears to answer everything, and the twelve ties only mean something once you know which layer of the model they are checking. For what happens to the model when the inputs move instead of the policies, the stress-testing article is the companion; for how the build keeps the linkage visible, the audit trail is the record.