Time is the hardest dimension

It looks like the easy one: months, quarters, years, everybody knows it. That familiarity is exactly the trap. Time is the dimension that quietly breaks more models than any other.

Ask a modeller to name the tricky dimension and they’ll point at the messy hierarchy: the product taxonomy that won’t sit still, the cost-centre tree that reorganises every year. Almost nobody points at time. Time feels solved. We’ve all used a calendar since we were six. There are twelve months, four quarters, a year rolls over, the end.

And yet, pull the thread on almost any modelling mess (the budget that won’t tie to the forecast, the actuals that land in the wrong column, the report two teams read two different ways) and surprisingly often you find a time problem wearing a costume. Different calendars. Different grains. A horizon that quietly changed. A period that closed while you were still writing to it. Time is the hardest dimension precisely because it doesn’t announce that it’s hard.

This piece is the map for the ones that follow. We’ll lay out why time is uniquely difficult (the half-dozen ways it refuses to behave like Products or Regions) and signpost where each thread gets picked up properly. (Calendars, the YTD/run-rate aggregations, the forecast horizon, restatements, phasing, the close cut-off: each earns its own walkthrough later in this series. This one is the lay of the land.)

Time isn’t one convention, and knowing which one you’re in is the skill

Here’s the first thing that makes time subtle. “Products” is a list your business owns and controls. “Time,” by contrast, comes with a set of conventions, and there’s more than one. Each is perfectly valid; the craft is knowing which one you’re working in, and not mixing two without noticing.

The example every finance person meets early is calendar year versus fiscal year. The calendar says the year ends on 31 December. A business might say it ends on 30 June, or 31 March, or the Saturday nearest the end of January. January is still January (nothing about the month has changed) but it’s month one to the calendar and month seven to a July-start fiscal year. The same date simply sits in a different place depending on which convention you’re standing in. There’s no contradiction there once you know which calendar you’re reading; the trouble only starts when a number from one is quietly lined up against a number from the other.

And fiscal-versus-calendar is just the opening move. Alongside it sit retail’s 4-4-5 calendars, ISO week numbering, 53-week years: a whole family of sensible ways to divide a year, each invented to solve a real problem in its own domain. Choosing a calendar, and then living comfortably with it, is a craft of its own, enough of one that it’s the very next article in this series. For now the point is gentle but worth holding onto: time looks universal, and it isn’t quite. It’s a choice, usually made before you model anything, that colours everything downstream.

The two relationships to time: recording it vs. planning across it

The second thing worth noticing is that finance relates to time in two genuinely different ways. They aren’t opposed (June is June in both) but they have a different nature, and a model usually has to serve both.

A system of record (the general ledger, the ERP) lives within a period. You’re in March. You post March transactions. March closes, locks, and becomes settled history. Time here is a series of boxes, and the job is to put each fact in the right box and close the lid. It’s not that a system of record denies the future exists; it simply doesn’t concern itself much with periods that haven’t happened yet. Backward-looking, single-period, settled.

FP&A relates to time differently. A planner rarely sits inside one period. They reason across a span of them. The work is largely about the relationship between periods: this month versus last, this year versus plan, the trajectory from where we are to where we’re heading. A forecast isn’t a box; it’s more like a line through time. Forward-looking, multi-period, and deliberately still open, because the future is the part you’re still working out.

A system of record asks “what happened in this period?” A plan asks “what is the shape of the next twenty?” The same calendar serves both questions perfectly well, which is exactly why they’re so easy to blur, yet a number that’s final in one world can still be a moving target in the other.

A lot of friction at the seam between actuals and plan comes down to this blur: a tool built to record one period at a time being asked to reason across twenty of them at once. A spreadsheet that does the first beautifully tends to do the second by hand, one copied formula at a time, which works right up until it quietly doesn’t.

Granularity: the grain is a means to an end

The third thing time asks of you is a grain (months, quarters, years) and there’s no universally right answer, because the grain is a tool, chosen to fit the job in front of it.

Sometimes the process itself implies the grain. Sometimes it’s simply a management call (“we don’t need monthly visibility here, quarterly is enough”) and that’s a perfectly good reason. Monthly is the FP&A default, but it’s a default, not a law. Finer gives you more resolution and more to maintain; a daily model sees every wobble, including the many that don’t matter. Coarser keeps the model light and calm but can’t see anything living inside the bucket: the cash dip in week three that a quarterly view reads as flat. Neither is better in the abstract; they’re better or worse for a given purpose.

A few cases where the domain more or less settles the grain for you:

• Retail tends to plan weekly. A month is too coarse when a single promotional week, or the timing of Easter, swings the quarter. The week is the unit the business actually lives in.
• A 13-week cash-flow is a fixture of the treasury world, and the number isn’t arbitrary. Thirteen weeks is a rolling quarter ahead: far enough to see trouble coming, near enough to still trust. The grain quietly encodes the horizon.
• Some industries plan much further than instinct suggests. An energy or utilities business may plan ten years out or more, and we’ve seen genuine 25-year simulations that were entirely justified, because they were modelling the depletion of a mineral deposit. When the asset itself has a multi-decade arc, a long horizon isn’t excess; it’s just honest.

A grain is chosen, not assumed, to fit the decision the model has to support. Sometimes the process dictates it, sometimes management does, and either way it’s worth choosing on purpose rather than inheriting out of habit. (When monthly genuinely isn’t enough (weekly, daily, and what they ask of you) is its own article further down this theme.)

Horizon: how far is information, and where does it become fiction

Granularity is how thick you slice. Horizon is how far you go, and it’s the fourth thing time makes you decide, usually without realising you’ve decided it.

Are you planning to the end of the current year? The next three to five? A rolling twelve or eighteen months that always shows the same distance ahead no matter what month it is? Each shape answers a different question, and each has a point past which the numbers stop being information and quietly become fiction: confident-looking cells that nobody can actually defend. Knowing where that line falls, where a forecast stops informing and starts performing, is enough of a question to get its own treatment later in the series.

The genuinely unorthodox approaches bend the grain to the horizon, refusing a single fixed slice. A telescoping plan might run the next 3 months at monthly detail, then 3 quarters, then 3 years: fine resolution where the future is close and knowable, coarsening deliberately as it recedes into the distance. It mirrors how planning attention actually works: sharp on the near term, impressionistic on the far. It’s also exactly the kind of structure a rigid, every-column-is-a-month spreadsheet makes harder than it needs to be.

Absolute time and relative time: one of the quiet power tools

This next one rarely gets named out loud, and it’s worth naming, because once you see it you start using it everywhere. Time in a model can be absolute or relative, and the difference is one of the more useful techniques a modeller can have in hand.

Absolute, or explicit, time is pinned to real dates: January 2024, Q3 2025, the fiscal year ending June 2026. You reach for it whenever the actual calendar matters: posting actuals, capturing seasonality, anything that has to line up with the real world on a specific day.

Relative, or implicit, time drops the dates entirely. The periods are defined by their position in a sequence: month one of operation, month two, month three; year one of the project, year two; the first month of a customer’s life, the second. Nothing here says “January.” It says “the first period, whenever that turns out to be.”

That second mode is easy to underrate, and it’s genuinely powerful. When you model in relative time you’re describing a shape rather than a schedule, and a shape can be reused. A unit-economics model that runs from “month one of a customer” applies to every customer, no matter when they signed. A project or asset model (a mine, a wind farm, a new product line) naturally lives in “year one, year two, year three,” because the economics follow the asset’s age, not the wall calendar. You build the pattern once in relative time, then anchor it to a real start date when you need to, and the same pattern can be re-anchored, or laid down at a hundred different start points, without rebuilding it.

Relative time lets you model the shape of something once and place it in real time later. It’s how cohort models, ramp curves, and project economics stay reusable: describe “month one onward,” then anchor it to whichever month one actually applies.

The skill, as ever, is knowing which mode you’re in, and being deliberate about the moment you convert between them. A relative-time template quietly dropped onto a real calendar without being anchored is a familiar way for a clean model to start producing puzzling numbers. Kept straight, though, the absolute/relative distinction is one of those techniques that makes a model both simpler and more reusable at the same time, which is rare enough to be worth the habit.

Time moves, and the past doesn’t always stay put

The last difficulty is the strangest, and it’s the one that has no parallel in any other dimension. Products don’t reorganise themselves overnight. Time does.

“Now” advances. The horizon slides forward every month, so the model isn’t a fixed object. It’s a thing with a moving frontier, the boundary between settled actuals and open plan creeping rightward at one column per close. And worse: the past itself can change. A restatement, a reorganisation, a corrected number reaches back and edits history you thought was sealed, which raises the genuinely hard question of how you keep yesterday’s reported figures comparable with today’s, and what you actually believed as of any given date. (Time travel of exactly this kind (when the past changes, and as-of reporting) closes out this theme; it’s too rich to compress into a paragraph here.)

This is what really sets time apart. Every other dimension is a list you arrange. Time is a list that arranges itself, advances on its own, carries direction and aggregation rules, and now and then revises its own history. Treat it as just another row of columns and, sooner or later, it will quietly catch you out, which is reason enough to give it the respect the rest of this series tries to.

Why the mess hides here

Pull the threads together and the article’s quiet claim comes good. A surprising share of modelling tangles that look like something else turn out, underneath, to be a time mismatch:

None of these arrive wearing a label that says time. They show up as a reconciliation that won’t close or a report two people distrust. But trace them back and the root is the same dimension everyone assumed was the simple one.

In Novi, time is a first-class dimension, not a row of columns

For most teams, time is hard partly because their tool doesn’t understand it. In a spreadsheet, time is just columns, and columns don’t know that Q1 contains January, that “last year” is twelve months back, or that a fiscal year starts in July. The modeller carries all of that in their head and re-encodes it, by hand, in every formula. Every difficulty above lands squarely on the person.

In Novi, time is a real dimension: a Type 4 Time dictionary that the platform genuinely understands. Define “Monthly from Jan 2023 to Dec 2027” and Novi builds the full hierarchy for you: the days roll into weeks, weeks into months, months into quarters, quarters into years, with the rollups already wired. You don’t hand-build sixty monthly columns and hope the quarter sums line up. The structure is the dimension.

And because the platform knows the structure, the hard aggregations stop being formula archaeology. Same period last year, running totals, period-over-period variance are period-aware operations that come with the time dimension, not things you rebuild each month and pray you got the offset right. The grain is yours to choose, the horizon is yours to set, and a different calendar is a property of the dimension, not a manual offset smeared across a thousand cells.

Which means the hardest dimension stops getting in the way, and goes back to being what it should have been all along: the axis you think in. (How Novi handles time automatically, what you genuinely never have to build, is a piece of its own, later in the library.)