Gregorian Year
A Gregorian Year is the standard calendar year defined by the Gregorian calendar, the civil calendar that runs January 1 through December 31.
Definition
A Gregorian Year is the standard calendar year defined by the Gregorian calendar, the civil calendar that runs January 1 through December 31. In Salesforce it is the default fiscal-year basis for any organization that has not switched to a custom fiscal year. A new org starts on this setting, so its fiscal year, quarters, and fiscal-year report filters all line up with the natural calendar.
Salesforce treats the Gregorian year as the foundation for its standard fiscal year, which the official documentation describes as one that follows the Gregorian calendar year but can start on the first day of any month you choose. When the start month is January, the fiscal year is fully Gregorian: Q1 covers January through March, Q2 April through June, Q3 July through September, and Q4 October through December. Date functions in formulas always read the Gregorian year regardless of how the fiscal year is set.
How the Gregorian year shapes dates, fiscal periods, and reports
The civil calendar Salesforce builds on
The Gregorian calendar is the internationally accepted civil calendar, in continuous use as the global standard for centuries. It fixes the year at 365 days, adds a leap day every four years (with the well-known century exceptions), and starts each year on January 1. Salesforce stores every Date and Datetime value against this calendar, so a CloseDate of 2026-03-31 means the thirty-first of March in Gregorian terms no matter what the org's fiscal-year setting is. This matters because contracts, invoices, and most accounting integrations all assume Gregorian semantics. When someone says a deal closed in 2026, they mean the Gregorian year. The term Gregorian Year shows up inside Salesforce mostly as a label that clarifies the platform is using its normal, unmodified date behavior rather than a company-specific calendar. Understanding this baseline makes the fiscal-year options easier to reason about, because each of them is a deliberate departure from the plain calendar that everyone already shares.
The default setting on a brand-new org
Every new Salesforce organization begins life with its fiscal year set to the Gregorian year. The fiscal year opens January 1 and closes December 31, and the four quarters sit on the obvious calendar boundaries. Because of this, a report filtered by This Fiscal Year returns the same records you would get by filtering on the current calendar year. Collaborative Forecasts shows period columns that match calendar months. Quotas, forecast rollups, and fiscal-year dashboards all read off this same January-to-December frame. Most business-to-consumer companies and smaller organizations never touch the setting, because their financial year already matches the calendar. The risk is inheriting an org and assuming the default is still in place. An admin who walks into a previously configured environment should confirm the fiscal-year setting before trusting any fiscal report, since a prior team may have switched to a non-Gregorian structure that silently shifts every period boundary away from the calendar months a newcomer expects to see.
Standard fiscal year: Gregorian with a different start month
The standard fiscal year is the first step away from a pure Gregorian year, and Salesforce documents it as a fiscal year that follows the Gregorian calendar year but starts on the first day of any month you choose. It still has twelve months and four quarters of three months each. What changes is where the year begins. A company on a February start has a fiscal year running February 1 through January 31, with Q1 covering February, March, and April. The labeling can name the year by either its starting or ending calendar year, so a September-to-August year might be called FY2026 or FY2027 depending on the org's convention. Once you pick a non-January start, fiscal-year report filters, forecast periods, and fiscal dashboards all follow the new schedule rather than the calendar. The formula functions, by contrast, keep reading the Gregorian year. That split is the most common source of confusion, because a fiscal report and a YEAR-based formula can disagree about which year a record belongs to.
Custom fiscal years and retail calendars
When a business cannot fit into twelve calendar-aligned months, it can enable a custom fiscal year. This option lets admins define periods that do not match the Gregorian structure at all, such as the 4-4-5, 4-5-4, or 5-4-4 quarter patterns common in retail, or a thirteen-period year, or a 52-or-53-week year. Custom fiscal years require period-by-period configuration in Setup and are chosen from a template that sets the week start day and the overall shape. Once a custom fiscal year is in place, Salesforce's fiscal report filters and forecast grids use those custom periods. The plain Gregorian arithmetic in formulas still works exactly as before, so YEAR(CloseDate) keeps returning the four-digit calendar year. There is one guardrail worth knowing: you cannot set a custom fiscal year's start or end date so that it overlaps a fiscal year already defined with the Gregorian-year template. Retailers and any organization with an unusual financial calendar are the typical users of this feature.
Formula functions always speak Gregorian
Salesforce formula functions ignore the fiscal-year setting entirely. YEAR(date) returns the four-digit Gregorian year, MONTH(date) returns 1 through 12 on calendar boundaries, DAY(date) returns the day of the month, and DATE(year, month, day) builds a value in the Gregorian calendar. TODAY() returns the current Gregorian date. None of these functions consult the org's fiscal configuration. This is helpful when you need stable, calendar-based math, for example computing the age of a record or grouping by true calendar year. It becomes a trap when an admin mixes a fiscal-year report filter with a formula field that uses YEAR. The filter follows the company's fiscal periods while the formula follows the calendar, so the same record can land in two different years depending on which logic you read. If you need the fiscal year inside a calculation, you have to derive it yourself from the date rather than expecting YEAR to know about the fiscal setting.
Forecasts, quotas, and period boundaries
Collaborative Forecasts leans on the fiscal-year setting to decide where one period ends and the next begins. With a Gregorian year, the forecast grid shows columns that match calendar months and quarters, which keeps the picture intuitive for everyone reading it. Switching to a standard or custom fiscal year recomputes every boundary, and that recalculation can move opportunities from one period into another in the middle of a quarter. Changing the fiscal year also clears existing user quotas, which then have to be re-entered by hand. Because of these effects, any change away from the Gregorian year should be timed for a clean break at the start of a new year, never mid-quarter. Document the current setting and the planned target before flipping it, warn the sales managers whose dashboards and quota numbers will move, and have the new quotas ready to load. Treating the change as a planned project rather than a quick toggle avoids a week of confused reporting and frustrated forecast owners.
When to leave it alone and when to change it
For most organizations the right answer is to leave the Gregorian year in place. If the company closes its books on December 31, the default already matches reality, and every fiscal report, forecast, and dashboard reads cleanly against the calendar that customers and finance teams already use. You only have a reason to move off the Gregorian year when the firm's financial year genuinely starts in another month, or when it runs a retail-style calendar that no calendar-month structure can represent. Even then, the standard fiscal year (Gregorian with a chosen start month) covers the majority of cases, and you should reach for a custom fiscal year only when the business truly needs irregular periods. Before any change, record the existing setting in the org's configuration runbook. It is the kind of quiet setting nobody thinks about until a fiscal report looks wrong, and writing it down saves the next admin from chasing a problem that was really just an unannounced fiscal-year switch made months earlier.
Check or change the fiscal-year setting in Setup
The Gregorian year is the default, so there is nothing to turn on to use it. The configuration task is the reverse: confirming the setting or deciding to move to a standard or custom fiscal year. Here is how to find and review the fiscal-year setting in Setup before you change anything.
- Open the Fiscal Year setup page
In Setup, use Quick Find to search for Fiscal Year and open it under Company Settings. The page shows whether the org is on a standard fiscal year (the Gregorian-based option) or has custom fiscal years enabled.
- Read the current start month
For a standard fiscal year, check the Fiscal Year Start Month. If it is January, the org is on a fully Gregorian year. Any other month means the fiscal year departs from the calendar even though it still uses Gregorian-aligned quarters.
- Decide whether a change is justified
Only move off the Gregorian default if the company's financial year actually starts in another month or needs irregular periods. If December 31 is the year-end, leave the setting as it is and document that decision.
- Plan the switch for a clean break
If you must change it, schedule the change for the first day of a new fiscal year. Warn forecast and dashboard owners, and have replacement user quotas ready, because changing the fiscal year clears existing quotas.
Follows the Gregorian calendar year but starts on the first day of any month you choose, keeping twelve months and four three-month quarters.
The calendar month a standard fiscal year begins. Set to January for a pure Gregorian year; any other month shifts every fiscal period away from the calendar.
Lets you define non-Gregorian period structures such as 4-4-5, thirteen-period, or 52/53-week calendars, configured period by period from a template.
- Changing the fiscal year deletes existing user quotas, which then must be re-entered by hand.
- Formula functions like YEAR and MONTH always use the Gregorian calendar, so they will not match a non-Gregorian fiscal-year report filter.
- A custom fiscal year cannot have a start or end date that overlaps a year already defined with the Gregorian-year template.
- Switching mid-quarter can move opportunities between forecast periods; always time the change for the start of a new year.
Prefer this walkthrough as its own page? How to Gregorian Year in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- Set Fiscal Year and Start Month in a Salesforce OrganizationSalesforce
- Set the Fiscal YearSalesforce
Straight from the source - Salesforce's reference material on Gregorian Year.
Hands-on resources to go deeper on Gregorian Year.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. When an org uses the Gregorian Year fiscal setting, when does its first quarter begin and end?
Q2. On a Gregorian Year org, YEAR(CloseDate) still returns the plain calendar year even after a custom fiscal year is proposed. Why?
Q3. A retailer needs a 4-4-5 weeks-per-quarter structure that the Gregorian Year cannot express. Which fiscal-year option fits?
Discussion
Loading discussion…