DualEntry supports a different fiscal year-end per company, so a group whose members close on different months can keep each set of books on its own year while still consolidating.
Setting the fiscal year
The fiscal year belongs to the company, not to a separate calendar object. Open Configuration → Company → Companies, select the company, and set its Fiscal Year section. The single setting there is the fiscal year-end month, which defaults to December.
Choosing March, for example, gives that company a fiscal year running April through March. Periods follow calendar months within that year; there is no separate period-pattern choice to make.
Set this before you post anything. The year-end month determines which fiscal year every transaction falls into, so changing it once a company has history reclassifies that history rather than only affecting what comes next.
Each company holds its own setting, so a group can mix year-ends without one company’s choice constraining another’s.
Week-based retail calendars are not supported. There is no 4-4-5, 4-5-4, or 5-4-4 pattern, no 13-period year, and no 53rd-week handling. Every company runs on 12 calendar-month periods, and only the month the year ends on is configurable.
Period status
Periods do not carry an open, closed, or locked status of their own. What controls whether you can post to a date is the period lock on the company, which stores a locked-through date for each of four sections: A/R, A/P, Other GL, and Non GL.
The practical effect is the same as closing a period, with one difference worth knowing: a lock is a date rather than a state. Locking A/R through the end of March closes every receivable dated on or before that day rather than closing a named period object. There is no “closed but adjustments allowed” middle state; a section is either locked through a date or it is not, and there is no override for a locked section.
Lock and unlock events are recorded in the audit trail, so reopening a section to post a late adjustment leaves a visible trace rather than passing silently.
Mixed calendars in a multi-entity setup
Different companies in the same organization can carry different fiscal year-ends. A parent on a December year-end can consolidate a subsidiary on a March year-end, because both sets of books are still kept in calendar months and it is the year boundary that differs, not the period grain.
That shared monthly grain is what makes the mix workable. A consolidated report covering January through March draws each company’s January, February, and March, regardless of which fiscal year those months belong to for that company.
Where the difference bites is close scheduling rather than reporting mechanics. Two companies with different year-ends hit their year-end close in different months, so the heavier annual work lands at different times even though the monthly cycle is shared.
Period locks are per company as well, which means each can close its own months on its own schedule without holding up the others.
Reporting alignment
Reports select by date range rather than by named period, so a multi-company report covering a set of months pulls the same months from every company in it. No proration is involved, because period boundaries are calendar months everywhere and therefore already line up.
Where the year-end difference does show is in anything year-relative. A subsidiary’s “fiscal year to date” is not the parent’s, so state the actual date range when you circulate a consolidated statement across companies whose years end in different months.
A year-to-date label means something different for each of them, and a reader who assumes otherwise will reconcile to the wrong number. Naming the range explicitly costs nothing and removes the ambiguity entirely.
The same caution applies to prior-year comparisons. Comparing a company against its own prior year is unambiguous; comparing two companies whose years end in different months means the two prior-year columns cover different sets of months. 
