When we start a OneStream implementation, one of the first things we need to understand is how the company manages its financial calendar.
For some organizations, this is simple. They follow January to December, close their books every month, and report twelve accounting periods.
But this is not always the case.
A global company may have subsidiaries using different fiscal years. One company may follow January to December, another may follow April to March, and a retail business may use a 4-4-5 calendar.
So before creating the OneStream application, we need to understand how these calendars work.
OneStream provides two important configurations for this requirement: the Time Dimension and the Time Profile.
They are related, but they do different things.
Let’s look at how they work and what we need to consider during application design.
What Is the Time Dimension in OneStream?
The Time Dimension defines the period structure used by the application.
For example, a standard monthly application has years, half-years, quarters, and months.
A typical structure looks like this:
| Level | Example |
|---|---|
| Year | 2026 |
| Half Year | H1 |
| Quarter | Q1 |
| Month | M1, M2, M3 |
OneStream combines the year and period into a Time member.
For example, 2026M1 identifies the first monthly period of 2026 within the Time Dimension.
The Time Dimension also determines the time frequency used for storing financial data.
This matters because the application may need monthly periods, weekly periods, or a different accounting-period structure.
The Time Dimension is not maintained like the Account or Entity dimensions. Its structure is defined at application creation.
What Is a Time Profile in OneStream?
A Time Profile controls how the application interprets and displays the periods according to a fiscal calendar.
Let’s say we have an application using twelve monthly periods.
Company A follows January to December.
Company B follows April to March.
Both companies have twelve accounting periods, but their fiscal years start in different months.
We can configure Time Profiles to support these different fiscal calendars.
For example:
| Fiscal period | Company A | Company B |
|---|---|---|
| M1 | January | April |
| M2 | February | May |
| M3 | March | June |
| M4 | April | July |
| M12 | December | March |
This is a simplified example of fiscal-period alignment.
The Time Profile provides the fiscal-calendar interpretation. It does not create a completely new underlying Time Dimension for every company.
OneStream includes a Standard Time Profile that follows January through December.
For other fiscal calendars, we create additional Time Profiles.
Difference Between Time Dimension and Time Profile
This is one of the important distinctions we need to understand when designing a OneStream application.
The Time Dimension defines which periods exist.
The Time Profile defines how those periods align with the organization’s fiscal calendar.
For example, a standard monthly Time Dimension contains twelve monthly periods.
A Time Profile can align those twelve periods to an April-to-March fiscal year.
However, if the business requires weekly-level data storage, simply changing the Time Profile does not convert a monthly application into a weekly application.
That requirement affects the Time Dimension structure.
| Design area | Time Dimension | Time Profile |
|---|---|---|
| Main purpose | Defines period structure | Defines fiscal-calendar alignment |
| Examples | Monthly, weekly, 13-period | January or April fiscal start |
| Configuration | Selected at application creation | Created in the application |
| Can support multiple configurations | One underlying structure per application | Multiple profiles can exist |
| Changes period storage frequency | Yes | No |
This is why we should not treat the two configurations as the same thing.
Example 1: Global Company With Different Fiscal Years
Let’s take a practical example.
We are implementing OneStream for a global company with operations in the US, India, and Australia.
The group reports on a January-to-December calendar.
However, the India finance team also needs reporting based on an April-to-March fiscal year.
Now, do we need to create another OneStream application for India?
Not necessarily.
If both requirements use the same monthly period structure, we can evaluate using different Time Profiles within the application.
The Standard Time Profile can support the January-to-December calendar.
Another Time Profile can support the April-to-March requirement.
OneStream allows multiple Time Profiles, and profiles can be assigned to cubes.
But we still need to understand the reporting and consolidation design.
A Time Profile does not automatically solve every difference between local statutory reporting and group reporting.
We need to confirm how the data is mapped, how fiscal periods align, and how the required results are reported.
For example, an India statutory report and a group consolidation report may need different period selections even though they use the same underlying financial data.
These requirements need to be tested before the design is finalized.
Example 2: Retail Company Using a 4-4-5 Calendar
Now, let’s look at another requirement.
A retail company does not follow normal calendar months for financial reporting.
Instead, it uses a 4-4-5 calendar.
In this structure, each quarter contains thirteen weeks.
The first accounting month contains four weeks, the second contains four weeks, and the third contains five weeks.
OneStream supports time structures for this type of calendar.
The documentation also describes 4-5-4 and 5-4-4 alternatives, along with 52-week and 53-week variations.
If the application needs data stored and processed at weekly frequency, we need to select the appropriate weekly Time Dimension structure when creating the application.
We also configure the Time Profile so that the fiscal-year start dates and period descriptions align with the business calendar.
One point to remember is that a weekly retail calendar may include a 53rd week in certain years.
We should not assume every year has exactly 52 weeks.
The calendar design needs to reflect how the finance team handles those years.
Example 3: Company With a Thirteenth Accounting Period
Some organizations use an additional accounting period for year-end adjustments.
For example, they may have twelve normal monthly periods and a separate adjustment period.
If the business requires thirteen distinct periods in the application, we need to review a custom Time Dimension definition.
OneStream supports custom period structures, including configurations beyond the standard twelve monthly periods.
We should clarify whether the company truly needs a separate thirteenth period or whether year-end adjustments can be managed through the existing periods and journal process.
These are different requirements.
If a separate accounting period is needed, we must design the period structure before creating the application.
We should not create a standard twelve-month application and assume we can add an additional period later through a Time Profile.
Why Calendar Design Matters Before Application Creation
This is probably the most important point for the implementation team.
OneStream documentation states that the Time Dimension structure cannot be changed after the application is created through normal application configuration.
For example, let’s say we create a standard monthly application.
Six months later, the finance team tells us that the application needs weekly-level reporting with a different underlying time structure.
This is not simply a matter of adding a new member or changing the Time Profile.
A different Time Dimension may require a new application and a migration approach.
OneStream documents a special conversion process for certain older monthly applications, but this is not a routine application configuration change.
So during requirement gathering, we need to confirm the calendar design before the application is created.
This decision can affect future application development, reporting, integration, and testing.
How We Configure a Custom Time Dimension
When a custom Time Dimension is required, the configuration starts in the System area.
The documented administration area is:
System > Time Dimensions
Here, we define the required Time Dimension type.
OneStream provides standard and custom options, including monthly and weekly configurations.
For example, a custom configuration may define the number of months in a quarter and the number of weeks in a month.
Once the Time Dimension definition is created, OneStream generates an XML file.
During application creation, we select that XML file as the Time Dimension Definition.
If we do not provide a custom Time Dimension Definition, OneStream uses the standard monthly Time Dimension type.
This selection is part of creating the application database.
We need to make sure the correct XML definition is selected before creating the application.
How We Configure a Time Profile
Time Profiles are configured under:
Application > Cube > Time Profiles
OneStream provides the Standard Time Profile by default.
When the business needs another fiscal calendar, we can create an additional profile.
Some of the important properties include the Fiscal Year Start Date, Fiscal Year Month Type, and fiscal-year naming convention.
For example, a fiscal year starting in April may require a different fiscal-year label than the calendar year.
OneStream provides the property called Fiscal Year is First Period’s Calendar Year.
This controls how the fiscal year is named when it starts in one calendar year and ends in another.
We also need to review period descriptions and short descriptions.
These affect how the periods appear to users in reports and other application interfaces.
After configuring the Time Profile, we assign the appropriate profile to the relevant cube.
We should validate the period alignment in reports rather than assuming that the profile is correct simply because it saves successfully.
What We Need to Check During Requirements Gathering
When we design the calendar structure, we normally start with the current financial reporting process.
We need to understand whether the organization follows monthly or weekly reporting, whether any entities have different fiscal years, and whether special adjustment periods exist.
We also need to understand how ERP periods map to OneStream periods.
For example, Workday Financials or SAP may provide accounting periods based on the source ledger’s fiscal calendar.
The source period may not directly match the reporting period required in OneStream.
So the integration design needs to account for that difference.
If the source sends accounting period 2026-01, we should not automatically assume that it belongs to the first fiscal period for every company.
The mapping depends on the source calendar and the target reporting design.
We also need to review how the company performs year-over-year comparisons, quarterly reporting, forecasting, and statutory reporting.
These requirements help determine whether a standard monthly structure is sufficient or a custom Time Dimension is required.
Common Calendar Design Issues
One common issue is confusing the Time Dimension with the Time Profile.
Changing a fiscal-year start month does not require a new Time Dimension when the existing monthly structure supports the requirement.
But introducing weekly-level data storage is a different decision.
Another issue is not confirming the thirteenth-period requirement before application creation.
If the finance team uses a separate adjustment period in the ERP, we need to understand how that period should appear in OneStream.
We should also avoid assuming that all subsidiaries use the same fiscal-year naming convention.
For example, a fiscal year running from April 2025 to March 2026 may be referred to as FY2025 or FY2026 depending on the organization’s policy.
This needs to be configured consistently.
Finally, we should validate the mapping between ERP accounting periods and OneStream reporting periods.
A correct-looking financial statement can still contain period mapping errors.
Conclusion
OneStream provides Time Dimensions and Time Profiles to support different financial calendar requirements.
The Time Dimension defines the underlying period structure and data storage frequency.
The Time Profile aligns that structure with the required fiscal calendar.
For enterprise implementations, we need to make this distinction early.
If a company needs twelve monthly periods with different fiscal-year start months, Time Profiles may support that requirement.
If the company needs a different time structure, such as weekly periods or thirteen distinct accounting periods, we need to evaluate the Time Dimension definition before creating the application.
The main objective is to ensure that the calendar structure supports financial consolidation, planning, integration, and reporting without requiring unnecessary redesign later.
Frequently Asked Questions
What is the difference between a Time Dimension and a Time Profile in OneStream?
The Time Dimension defines the period structure and storage frequency. The Time Profile controls how those periods align with a fiscal calendar.
Can OneStream support an April-to-March fiscal year?
Yes. OneStream supports custom Time Profiles that can align a twelve-month period structure to a fiscal year beginning in April.
Does OneStream support a 4-4-5 calendar?
Yes. OneStream documents 4-4-5, 4-5-4, and 5-4-4 configurations, including weekly Time Dimension options.
Can we change the Time Dimension after creating an application?
The Time Dimension structure is fixed during normal application configuration after creation. A different structure generally requires planning a new application or reviewing a supported migration path.
Can we have multiple Time Profiles in one application?
Yes. OneStream supports multiple Time Profiles for different fiscal-calendar requirements.
Does a Time Profile create new accounting periods?
No. It aligns and describes the periods defined by the application’s Time Dimension. A different underlying period structure must be addressed through the Time Dimension configuration.