Subtraction is the easy part
Every finance team compares periods, and almost every one does it by exporting two sets of numbers and putting them next to each other in a spreadsheet. The subtraction takes seconds. The half-day goes on making the two sides comparable.
One export has categories in a slightly different order. One period includes an account the other did not. A category was renamed in April, so the same cost appears under two names. A large transfer between own accounts sits in one side and not the other. None of these are analysis problems — they are assembly problems, and they consume the time that was meant to go on understanding the difference.
Period comparison in FlowParse is the same operation done over one dataset instead of two exports. Both periods come from the same extraction, carry the same category list and the same account tags, and are bounded by transaction date rather than by which file they arrived in.
The four ways a comparison quietly breaks
Comparisons rarely fail loudly. They produce a plausible number that is wrong for a reason nobody looks for, because the number looks like the sort of number you were expecting.
| What went wrong | How it looks | How it is caught |
|---|---|---|
| A missing statement | Spending appears to fall | Balance continuity across the series |
| An account added mid-year | Spending appears to rise | Account tag on every row |
| A category renamed | One line collapses, another appears | Category list compared between periods |
| Transfers included | Both sides inflated, unevenly | Internal movement excluded by rule |
The first two are the dangerous pair, because they produce exactly the story people are primed to believe. A quiet month is easy to accept. A jump after a good quarter is easy to accept. Neither gets challenged, and the underlying data problem persists into every subsequent comparison.
Where a period actually starts
Statements do not respect calendars. A card account might run from the 15th to the 14th, a current account from the 1st, and a second entity from whatever date it was opened on. If a comparison treats “the file” as “the month”, the periods overlap and the difference is partly an artefact of billing cycles.
Boundaries are therefore taken from transaction dates on the rows, not from the document. A statement spanning two calendar months contributes to both, split at the date. This sounds obvious and is the single most common reason a hand-built comparison disagrees with the accounting system.
It also means a period can be closed before every statement covering it has arrived, and reopened when the late one lands. That is honest behaviour rather than a shortcoming — the alternative is a period that looks complete and is not.
For fiscal calendars that do not follow calendar months, supply the boundaries and the comparison follows them. What it will not do is infer a 4-4-5 calendar or a 53-week year from the data, because guessing wrong there is worse than asking.
Consistency beats sophistication
A crude comparison applied identically to both periods is more useful than a refined one applied differently. This is the principle the whole feature is built on, and it runs against the instinct to improve the categorisation whenever you notice something imperfect.
Improving categories mid-year is not free. Every improvement breaks comparability with everything before it. That does not mean never improving — it means improving deliberately, at a boundary, and restating the prior period when you do, so that the change shows up as a change in presentation rather than as business performance.
The practical rule: change the category list once a year, at the point the budget is rebuilt. In between, resolve awkward transactions with notes rather than with new categories. The categorisation page covers how to keep that list stable when new payees appear every month.
How it works
1 · Convert both periods
Every account for both ranges, up to 100 files at a time. Older periods that exist only as scans go through OCR first.
2 · Continuity checked
Each statement's closing balance is recalculated from its rows and the series is checked for gaps, so a missing month is a flag rather than a fall in spending.
3 · One category list
The same categories applied across both ranges, with any category that exists in one period and not the other surfaced rather than silently zeroed.
4 · Bounded by date
Periods are cut on transaction date, so billing cycles that straddle a month end do not distort either side.
5 · Compared
Category by category, with the absolute difference and the underlying transactions reachable from every row.
6 · Exported
Excel or CSV with fixed columns, so a comparison sheet built once keeps working next month instead of being rebuilt.
Before and after
The difference is not in what the final table looks like. It is in how much of the preparation time was spent making two sides agree on what they were measuring.
Before
- Two exports, different column orders, aligned by hand
- Categories spelled differently between the periods
- An account that only exists in one of the two
- Transfers left in, inflating both sides unevenly
- No way to see which payments make up a difference
- The sheet rebuilt from scratch every month
After
- One dataset, both periods drawn from it
- One category list, differences between periods flagged
- Account and file recorded on every row
- Internal movement excluded by rule, not by memory
- Every difference opens onto its transactions
- Fixed columns, so the sheet survives to next month
Like for like
A raw comparison answers “what changed”. A like-for-like comparison answers the more useful question: what changed among the things that existed in both periods.
The distinction matters as soon as anything is added or removed. Open a second office and total costs rise; that is not a cost-control story, it is a growth story, and mixing the two produces a report that cannot support either conversation. Separating them costs one extra column and changes what the report can be used for.
The same applies to payees. A supplier used all year and a supplier engaged in month eight are different kinds of increase. Splitting the difference into “same payees, different amounts” and “payees that are new” is often the single most informative cut available, and it takes no judgement to produce.
Year over year, and why it is harder than it looks
Comparing a month against the same month last year removes seasonality, which makes it the most informative comparison available — and the one most likely to be built on inconsistent data, because a year is long enough for everything to have changed.
In twelve months a business typically changes banks or adds an account, renames categories, changes accounting system, and alters who codes the transactions. Any one of those makes the two years not directly comparable, and none of them announce themselves in the numbers.
Working from statements rather than from ledger exports sidesteps a good deal of this, because the statement is the same document type regardless of what system was in use at the time. A year-old scanned PDF from a bank you have since left extracts into the same columns as last month’s download — which is exactly what makes the comparison possible at all.
What remains is the category question, and it has to be handled deliberately: either re-categorise the older period with today’s list, or accept that certain lines are not comparable and say so on the report.
Seasonality is not variance
Month against prior month is the easiest comparison to produce and the easiest to over-read. In any business with a season, most of the month-on-month movement is the season.
Three cuts of the same data usually resolve it. The current month against the prior month shows momentum. The current month against the same month last year removes the season. Year to date against year to date smooths both. Presenting all three costs two extra columns and prevents most of the wrong conclusions that a single comparison invites.
Where a business has a genuine annual cycle, it is worth writing the expected shape down once — which months are heavy, which are light — and comparing against that shape rather than against a flat expectation. Doing so converts a recurring surprise into a routine confirmation.
What is new this period
One of the most useful outputs is not a comparison of totals at all: it is the list of payees that appear in this period and did not appear in the last.
New payees are where unplanned spending starts, where duplicate subscriptions begin, and occasionally where something has gone genuinely wrong. The list is usually short — a handful of rows in a normal month — and it takes a minute to read. Very few reporting processes produce it, and nearly everyone who starts finds something in the first month.
The mirror image is worth the same minute: payees that appeared last period and have vanished. Sometimes that is a cancelled service working as intended. Sometimes it is a payment that failed and nobody noticed, which tends to be discovered later and more expensively.
Which comparison answers which question
People ask for “a comparison” and mean one of four quite different things. Picking the wrong one produces a correct number that answers a question nobody asked.
| Comparison | Answers | Weakness |
|---|---|---|
| Month vs prior month | Is anything moving right now | Mostly seasonality in most businesses |
| Month vs same month last year | Has anything structurally changed | A year is long enough for the data to have changed too |
| Year to date vs year to date | Are we on track overall | Slow to reveal a change that started recently |
| Quarter vs quarter | Is a trend real or a blip | Too coarse to act inside the quarter |
The second and third rows together cover most management needs, and the pattern between them is more informative than either alone. A month that looks bad while the year to date looks fine is almost always timing. A month that looks fine while the year to date drifts is a slow leak — the failure mode no single period comparison would ever surface, and the reason a cumulative column is not optional.
A practical habit: run the second and third every month as standard, and reach for the first only when someone asks what changed since last month. Producing all four every month is how a two-page report becomes a pack.
What you get
Differences you can trace
Every comparison row opens onto the transactions that make it up, so a question about a number is answered in seconds rather than in a follow-up.
Assembly time back
The hours that went on aligning two exports go away, because there are no longer two exports.
Errors caught before analysis
Missing statements, added accounts and renamed categories surface as flags rather than as plausible business stories.
Comparisons that survive
Fixed columns and a stable category list mean a sheet built in January still works in November.
Where it gets used
Budget reporting. The actual side of a budget-versus-actual comparison is a period comparison with a plan column added, and it inherits every one of the consistency problems above.
Cost review. Two periods side by side is how a subscription nobody uses gets found, how a price rise gets noticed, and how a supplier that quietly doubled becomes a conversation.
Cost centre reporting. Comparing a department against its own prior period is more useful than comparing it against another department — the detail is on the cost centre spend report page.
Preparing a budget.Last year’s actuals, compared to the year before, is the raw material for next year’s plan — the method is in the budget-building guide.
Group reporting. Where several entities close together, comparison follows combination — see multi-entity reconciliation.
What it will not do
It will not explain a difference. It shows that marketing spend rose by a given amount and which payments account for it; whether that was planned, effective or wise is not in the data.
It will not apply accounting judgement. Accruals, prepayments and revenue recognition sit outside a cash-based comparison, and the month-end close checklist covers where those belong.
It will not invent a fiscal calendar. Supply your period boundaries and it follows them exactly; it does not guess at 4-4-5 or a 53-week year, because a wrong guess there is worse than a question.
And it will not repair categories that were inconsistent when they were assigned. It can flag that a category exists in one period and not the other, which is most of the value — but restating the earlier period remains a decision someone has to make.