Bikram Sambat Financial Year Explained

If you run a business in Nepal, you live in two calendars at once. Your payment provider timestamps every transaction in the Gregorian (AD) calendar. Your tax filings, your fiscal year, and half your bank paperwork run on the Bikram Sambat (BS) calendar. Most of the time you switch between them without thinking. In reconciliation, that casual switching is where things quietly break.

This article explains how the two calendars relate, why the Nepali fiscal year runs on dates that look strange to outsiders, and why any serious reconciliation has to be Bikram Sambat-aware rather than treating BS as a display option.

Two calendars, one business

Bikram Sambat is the official calendar of Nepal. It runs roughly 56 years and 8 months ahead of the AD calendar - so the AD year 2026 falls across BS 2082 and 2083. But the offset is not the hard part. The hard part is that the two calendars do not line up cleanly.

• Month boundaries do not match. A BS month does not start on the first of an AD month. Poush might run from mid-December to mid-January in AD terms. So "this month" means two entirely different date ranges depending on which calendar you mean.
• BS month lengths vary. A Bikram Sambat month can have 29, 30, 31, or even 32 days, and which one is not fixed by a simple rule - it follows an official almanac. You cannot compute BS dates with arithmetic alone; you need a conversion table.
• The year rolls over mid-summer. More on this below, but the BS new year lands in mid-April, and the fiscal year rolls over even later.

None of this matters when you are chatting about dates. All of it matters when you are matching a provider report to a bank statement and a filing period.

The Shrawan-to-Ashadh fiscal year

Nepal's fiscal year does not follow the Bikram Sambat new year, and it certainly does not follow the AD one. It runs from the first day of Shrawan to the last day of Ashadh - roughly mid-July to mid-July in AD terms.

So the fiscal year written as 2082/83 begins around 16 July 2025 and ends around 16 July 2026. Every VAT return, income tax filing, and audit in the country is anchored to this window. The Inland Revenue Department defines reporting periods against it, and Nepal Rastra Bank frames banking-sector reporting the same way.

This is not a quirk you can ignore. Your monthly VAT period, your quarterly figures, your annual close - all of them are cut on Shrawan-Ashadh boundaries expressed in BS months. If your reconciliation groups transactions by AD month, its periods will never line up with the periods you actually file against.

Where the mismatch bites in reconciliation

Reconciliation is fundamentally about matching things that should agree. Dates are one of the primary keys you match on. When two systems express the same date in different calendars, matching quietly fails even though the money is perfectly correct.

Here is where it shows up in practice:

• Provider reports vs bank statements. eSewa, Khalti, and Fonepay report in AD timestamps. Some Nepali bank statements carry a BS value date. Match a settlement to a bank credit on date alone and a naive comparison misses, because 2082-03-32 and 2026-07-16 look like different days to a computer even though they are the same day.
• Period cut-offs. A settlement that belongs to Ashadh (this fiscal year) might carry an AD date in July that a naive system files under the next period. One transaction lands in the wrong year, and your year-end totals no longer tie out.
• Month-end grouping. If you close and reconcile by BS month - as your filings require - but your data is grouped by AD month, every monthly total is a blend of two BS months. The numbers are meaningless for compliance.

What "BS-aware reconciliation" actually means

Being Bikram Sambat-aware is not about displaying dates in Nepali. It is about doing the matching and grouping logic in the right calendar. In practice that means:

• Convert once, match consistently. Every date - from providers, banks, and orders - is normalised to a single internal reference, then converted back for display and filing. You never match an AD string against a BS string.
• Use a real conversion table. Because BS month lengths are almanac-driven, conversion needs a lookup table, not a formula. An approximate conversion will be off by a day near month boundaries, which is exactly where period cut-offs live.
• Cut periods on BS boundaries. Daily closes roll up into BS months, which roll up into the Shrawan-Ashadh fiscal year. The period boundaries are BS-defined even though the underlying timestamps are AD.
• Handle the year-end straddle. Transactions around mid-July need care - a payment captured on 15 July and settled on 17 July can straddle the fiscal boundary. The close has to place each one in the correct year deliberately, not by accident of which timestamp it read.

Get this right and your daily close, covered in what a daily close is, naturally rolls up into filing-ready periods. Get it wrong and your bank statement reconciliation will throw residuals that are really just calendar artefacts.

Why this is worth getting right

Calendar-correctness sounds like a formatting detail. It is actually a compliance and accuracy issue. Your VAT is filed against Shrawan-Ashadh periods cut on BS months. Your auditor expects the year to end at Ashadh, not December. Your bank paperwork may already be in BS. If your reconciliation lives only in AD, you are constantly translating at the boundaries, and every translation is a chance to misfile a rupee.

The cleaner approach is to make the calendar a first-class part of the reconciliation itself, so that a proven daily close is also a correctly-dated one. RakamHQ handles both calendars natively - matching AD provider timestamps to BS-dated bank lines, and cutting closes on the Shrawan-Ashadh boundaries your filings actually use - so the date is never the reason a rupee ends up in the wrong place.

Frequently asked

When does Nepal's fiscal year start and end?

It runs from the first day of Shrawan to the last day of Ashadh, roughly mid-July to mid-July in AD terms. The fiscal year 2082/83, for example, begins around 16 July 2025 and ends around 16 July 2026.

Why can't Bikram Sambat dates be converted by formula?

BS month lengths vary between 29 and 32 days according to an official almanac, not a fixed rule, so accurate conversion needs a lookup table. An approximate conversion drifts by a day near month boundaries, exactly where period cut-offs sit.

How does the calendar mismatch break reconciliation?

Providers timestamp in AD while some bank statements carry BS value dates, so a date-based match can miss even when the money is correct. Transactions near mid-July can also land in the wrong fiscal period if filed by the wrong calendar.

Which date determines the VAT period, sale or settlement?

VAT is owed in the period of the supply, not the period the money settled. A settlement date is a banking event, so reconciliation must place each sale by its supply date in the correct BS-defined period.

Keep reading

What Is a Daily Close, and Why Prove It?

Read

VAT on Digital Payments in Nepal

Read