A Financial Year That Does Not Start in January
A surprising amount of business software contains a quiet assumption that a year starts on 1 January. It is never written down, it never appears in a specification, and it is almost never wrong in a demo — because a demo is a month long and a year is not. It surfaces about fourteen months into an implementation, when somebody prints a year-to-date figure for a board pack and it is three months too long.
For a great many organizations that assumption is harmless, because their year genuinely does start in January. For the rest — and it is not a small rest — it is a defect that produces a confident, plausible, wrong number, which is the worst kind. This post is about which parts of an operations system a non-calendar financial year actually touches, what it does to this one specifically, and the five-minute discipline that makes it a non-issue while the proper fix waits.
The years that are not the calendar
Start with the fact that makes this a market question rather than a preference. States run their own fiscal years, and a good many of them do not begin in January.
| Market | The state's own fiscal year | Why a business there notices |
|---|---|---|
| Egypt | 1 July – 30 June | Public procurement rounds, subsidy and programme cycles and statistical returns sit on the state's calendar. Companies commonly close in June or December, so two conventions coexist in one market and a group can hold both. |
| Ethiopia | 8 July – 7 July | Follows the Ethiopian calendar rather than the Gregorian one, so the year boundary does not land on the first of any Gregorian month. Nothing that assumes month boundaries handles it cleanly. |
| Japan | 1 April – 31 March | The convention the roadmap for this post named first, and the reason is that it is near-universal among Japanese corporates rather than merely governmental. |
| India | 1 April – 31 March | The financial year is April to March for the state and, in practice, for almost everyone reporting to it. |
| Australia and New Zealand | 1 July – 30 June | A June year-end is the default assumption in both, not the exception it looks like from Europe. |
| United Kingdom | 1 April – 31 March (government) | And the personal tax year runs 6 April to 5 April, which does not begin on the first of a month at all — the single most awkward boundary on this table. |
| United States | 1 October – 30 September (federal) | Federal contractors and grantees inherit an October start regardless of how their own books are kept. |
| South Africa | 1 April – 31 March (government) | Public-sector suppliers and grant recipients report on it; private companies mostly do not. |
Read that table for what it is
These are the fiscal years of the states themselves. In most of these markets a private company sets its own year-end when it registers, and nothing above binds it. The reason the table matters anyway is second-order and it is the practical half: where the state's year is not the calendar, everything organized around the state follows it — tender rounds, subsidy programmes, donor and grant cycles, statistical returns, public-sector payment runs. A business supplying that sector inherits the rhythm whether or not its own books close in December. Nothing here is advice on what applies to you; your auditor sets your year-end and your contracts set your reporting dates.
What a non-calendar year actually touches
The useful surprise, when we read our own code against this question, is that the answer splits cleanly in two — and the half most people worry about is the half that is fine.
Period-agnostic, and correct as it stands
- Closing the books. Accounting periods close and reopen one month at a time, keyed on a year-and-month. There is no year object anywhere in that mechanism, which means there is no year object to be wrong. Twelve closes from April to March are a financial year and nothing objects.
- Every report's date range. Reports read an explicit start date and end date. Type April to March and you get April to March, with no reinterpretation on the way through.
- Exports and PDFs. They run off the same two dates as the on-screen report, so a correctly dated report exports correctly dated.
- Comparative periods you construct yourself. Run the range twice with different dates and compare. Coarse, and exactly right.
Calendar-anchored, and quietly wrong for you
- The "This Year" and "Last Year" presets. They select the calendar year containing today. Always, with no setting that changes it.
- The quarter presets. Calendar quarters. If your year starts 1 April or 1 July the boundaries happen to align and only the numbering is wrong — your Q2 is the system's Q3. If it starts anywhere else, the boundaries are wrong too.
- Default date ranges on reports you open without choosing a period. Several default their start date to 1 January.
- Yearly trend charts. Multi-year comparisons bucket by calendar year, so each bar is three months out of step with the year it is labelled as.
- Anything scheduled. A report set to run with a preset carries the preset's assumption every time it fires, unattended, into somebody's inbox.
That is a much better position than "it does not support fiscal years", and a much worse one than "it is fine". The ledger is agnostic. The furniture on top of it is not, and the furniture is what people click.
What the wrong number looks like
It is worth seeing the size of it, because the reason this survives so long in so many organizations is that the output never looks wrong. Take a business whose financial year runs 1 April to 31 March, on 12 August, asking for the year to date.
Year to date, asked for two ways on the same day
Nothing on the page is marked wrong, because nothing is wrong — the query did exactly what it was asked. The figure is a truthful answer to a question nobody meant to ask, it carries a label that makes it look like the answer to the question they did mean, and the three extra months are ones already signed off in a prior year's accounts. Comparatives are worse than the level: a year-on-year growth figure built this way compares two overlapping seven-and-a-half-month windows and calls the result annual growth.
The five-minute discipline, starting today
None of the below waits on anybody building anything. The explicit date path is complete and correct, so all of this is about routing around a convenience layer rather than around a limitation.
-
Declare the year and quarter presets unavailable
Write it down, tell the people who run reports, and mean it. "This Year", "Last Year", "This Quarter" and "Last Quarter" are the four to strike. The day and week presets are unaffected and the month presets are fine as long as nobody adds them up into a quarter that is not yours.
-
Type the dates, and type the same dates every time
The custom range is the whole product as far as periods are concerned — the presets do nothing but fill those two fields in. Keep your period boundaries written somewhere shared rather than recalled, because the most common error is not the preset, it is somebody typing the year-end a day out and nobody being able to tell from the output.
-
Close every month, on time, without exception
This one is quietly the most important. Because there is no year object, your financial year exists only as the set of monthly closes inside it. A month left open is not a small administrative untidiness in this design; it is a hole in the only structure your year actually has.
-
Audit anything that runs unattended
Scheduled reports, dashboard tiles, and any default range on a report somebody opens without choosing a period. Several default to a 1 January start. A person typing dates catches their own mistake eventually; a scheduler never does, and it sends the same wrong period every month to the same people, who stop reading the dates after the second one.
-
Put the year-end on the record, in words, where a person reads it
A project description, a report header, an organization profile field — anywhere a human will see it before interpreting a figure. It is not a setting and it will not change any behaviour. It changes whether the person reading a number knows which year it belongs to, which is the actual failure being managed here.
Five questions for any vendor, including us
The fiscal-year interrogation
None of these takes more than two minutes in a demo, and every one of them has a wrong answer that sounds fine.
Is the financial year a setting, or an assumption?
Make them prove it: Ask them to show you where it is configured. Not describe it — show it. An assumption is not a defect on its own; an assumption nobody can locate is.
What does "This Year" select for an organization whose year starts in April?
Make them prove it: Set the year to April, then click the preset and read the dates it filled in.
Are the quarter presets derived from the financial year or from the calendar?
Make them prove it: Ask what Q1 is. If the answer is "January to March" and your year starts in July, the labelling is wrong even where the boundaries are not.
What period does a scheduled report use when it fires?
Make them prove it: Have them schedule one and show you the range it resolves to on the next run, rather than the range it showed when it was set up.
Does closing a period work at year level, or month by month?
Make them prove it: Ask them to close a period and watch which control they reach for.
That last criterion is the one that inverts. Month-by-month closing looks less sophisticated than a year-end routine and it is the answer you want, because a mechanism with no year in it cannot hold the wrong year. The systems that break hardest on a non-calendar financial year are the ones that modelled the year most confidently.
What AWRA OpsHub does today
- Accounting periods that close and reopen month by month, with no year construct anywhere in the mechanism — so a financial year running April to March, or July to June, closes correctly with nothing reinterpreted.
- An explicit start date and end date on every report, honoured exactly as typed, through the on-screen view, the export and the PDF alike.
- A shared date-range control used across reports, so the behaviour is the same wherever you meet it rather than differing module by module.
- Month and week presets that are correct for everybody, because a month is a month in any fiscal convention.
What it does not do
- Any fiscal-year setting. There is no such configuration anywhere in the product — we checked as an absence rather than assuming it, and it is absent.
- Year and quarter presets derived from anything but the calendar. "This Year" is the calendar year containing today, in every module that offers it.
- Fiscal-year-aware default date ranges. Several reports open with a start date of 1 January when you have not chosen a period.
- Fiscal-year buckets on multi-year trend charts, which group by calendar year.
- Any year-end close routine, roll-forward of balances, or opening-balance carry as a distinct step.
- Anything at all that handles a year boundary falling mid-month, such as a 6 April or an Ethiopian-calendar start.
Not ours, by choice
- We do not tell you what your financial year should be, and nothing in this post is advice on what any market requires of you. Your year-end is set by your own constitution, registration and auditor.
- We are not an audit or statutory-filing service. Producing the accounts is yours and your accountant's; what we owe you is figures for the period you actually asked for.
This is a genuinely modest build and we would rather say that than dress it up. The hard part — a ledger with no opinion about years — is already the way round we would want it. What is missing is a stored financial-year start on the organization, and then presets and default ranges computed from it instead of from January: "This Year" becomes your year, "Q1" becomes your first quarter, the report defaults open on your year-to-date, and the trend charts bucket by your year. That is a setting, a small support class and a sweep through the places that call for a calendar year — bounded, specifiable and testable, and it is one of the better-value builds on this site precisely because the foundation underneath it does not need touching. A year boundary that falls mid-month, like 6 April or an Ethiopian-calendar start, is a genuinely harder second phase and should be scoped separately rather than assumed into the first. As always: you describe the requirement, we return a written scope, timeline and cost, and you decide before anything starts. The precedent that market-specific work gets finished here is Kenya, where a live tax-authority integration and a maintained statutory payroll engine are both ours to run.
We went looking for a fiscal-year setting expecting to find one half-built, and found instead that nothing anywhere references the concept — while the part everyone assumes will break, closing the books, turned out to be immune because it never modelled a year in the first place. That is the opposite of the shape we expected and it is why the recommendation is a discipline rather than a warning.
A fiscal year is a setting we have not been asked for yet
Nothing in the design resists it. The reason it does not exist is that no customer has put the requirement in writing in front of us, which is a different situation from a product that cannot hold one.
A year start on the organization
One stored date, from which every period the system offers is derived rather than assumed.
Presets that mean your year
"This Year", "Last Year" and the four quarters computed from your boundary, in the shared control every report already uses.
Trends bucketed your way
Multi-year comparisons grouped by financial year, so each bar is the year it is labelled as.
Defaults that open on your year to date
Including on anything scheduled, which is where a calendar assumption does its quietest damage.
We do not promise roadmap dates. You describe the requirement, we return a written scope, timeline and cost, and you decide before anything starts.
Tell us when your year startsThe short version
A financial year that does not start in January is not an exotic requirement — it is the norm in several of the largest economies on earth and it is the state's own convention in Egypt, Ethiopia, Japan, India, Australia and more. Here, the part that would be expensive to fix is already right: the books close month by month and every report honours the dates you type, so nothing about your year is unrepresentable. The part that is wrong is a row of convenience buttons and a handful of defaults, and until those derive from a year-start setting, the answer is to stop using four presets and to check anything that runs without a person watching. That is a small ask. It is much smaller than the board pack that overstated the year by three months and nobody caught for two quarters.
Your year does not start in January
Tell us when it does start and which reports your board and your regulators actually see, and we will tell you which of them are safe as they stand, which need a typed date range, and what a proper fiscal-year setting would cost you. If your boundary falls mid-month, say so early — that is the harder half and we would rather price it honestly than discover it.
See plans & pricingFrequently asked questions
Can I set a financial year that does not start in January?
Not as a setting — there is no fiscal-year configuration in the product. What there is instead is a ledger that has no opinion about years at all: accounting periods are closed month by month, so twelve closes from April to March are a financial year and nothing objects. Every report also accepts an explicit start and end date. What is calendar-anchored is the convenience layer — the quick-period presets and the default date ranges.
What does the "This Year" preset actually select?
The calendar year containing today, always. For a business whose year runs April to March, asking for "This Year" in August returns January to August — which silently includes three months belonging to a financial year that has already been closed and reported.
Are the quarter presets wrong too?
Only sometimes, which makes them more dangerous than the year preset. If your year starts on a quarter boundary — 1 April or 1 July — the calendar quarters line up with yours and only the numbering differs: your Q2 is the system's Q3. If your year starts anywhere else, the boundaries themselves are wrong.
So what should we actually do?
Type the dates. Every report reads an explicit start and end date, and that path is complete and correct — the presets only fill those two fields in. Treat the year and quarter presets as unavailable, close every month on time, and check the default date range on any scheduled or dashboard report, because the defaults start on 1 January.
Why does this matter in North Africa specifically?
Egypt's state fiscal year runs 1 July to 30 June, and the rhythm attached to it — public tenders, subsidy and programme cycles, statistical returns — follows the state rather than the calendar. A business supplying the public sector there inherits that rhythm whatever its own year-end is.
