Test an accounting system against your actual fiscal calendar

A vendor can say that its accounting system supports fiscal years without showing how your company's periods will behave. Before the demonstration, supply the approved start and end dates for a complete year and the following year's opening period. Include any unequal period lengths. The test should use those dates, not a convenient January-to-December example supplied by the salesperson.

Name the reporting calendar you are testing. A management calendar, statutory reporting year, payroll calendar and tax year can serve different purposes. Ask the relevant company owners to identify which calendar controls the ledger and which calendars belong in separate reports. Software configuration should implement that decision rather than make it implicitly.

For a hypothetical 4-4-5 quarter, the three periods contain 28, 28 and 35 days, a total of 91 days. That small example is enough to expose a report that silently treats each period as a calendar month. Use a dated version of the example so there is no ambiguity about the boundary between periods.

Keep the calendar file under a named owner's control during selection. If the company has not settled a future extra week or a transition year, describe that as an unresolved requirement. A vendor's willingness to configure something later is not evidence that the eventual calendar and reports will work together.

Microsoft's Business Central documentation explains that accounting periods can have different lengths, including a manually configured 4-4-5 arrangement. It also states that accounting periods do not control posting dates: separate posting-date settings perform that function. This distinction is useful when questioning any product's calendar controls.

Have the demonstrator identify the fields that define a period, the settings that permit posting and the actions that close a fiscal year. Ask which actions can be reversed and which require special correction procedures. Similar labels such as closed or locked may describe different consequences.

Enter a permitted transaction dated in the prior period and another outside the ordinary user's allowed posting range. Observe the actual result under that user's role. The calendar may classify a date correctly while still allowing an inappropriate posting, or it may block an adjustment the controller needs to make through a controlled process.

Record the configuration needed to reproduce each result. Avoid accepting a demonstration conducted entirely with unrestricted administrator access. The relevant question is how the finance team will use the calendar during an ordinary close, including the person responsible for approved late adjustments.

Prepare a short set of synthetic postings with recognizable amounts. Include the last day of a four-week period, the first day of the next period, the last day of a five-week period and the first day of the next fiscal year. Add a transaction whose document date differs from its posting date.

Before entry, write down the expected fiscal period for each posting. Then inspect the ledger inquiry, period totals and exported report. The expected assignment should be the same wherever the report is intended to use posting dates. If another screen deliberately uses document dates, its label and purpose should make that difference visible.

Check the treatment of an extra week where the approved calendar requires one. The demonstration should show the exact period receiving it and the next year's opening date. A free-text label saying week 53 does not prove that date filters, balances and comparative reports use the extra days.

Use at least one period with no transactions. A report should still represent the approved sequence of periods in the way finance expects. Otherwise a missing column can shift a reader's interpretation of every later amount, particularly when a spreadsheet export removes empty periods.

Ask the vendor to produce current-period, prior-period and prior-year comparisons from the test data. Read the underlying date ranges, not only the column captions. A formula that subtracts one calendar month may be unsuitable for an uneven reporting calendar even though the displayed totals look plausible.

Repeat the comparison at a year boundary and at the extra-week boundary, if applicable. Finance should decide whether a particular management report compares named periods, matched weeks or another approved interval. The system needs to disclose the interval used; it should not silently select whichever comparison yields a tidy table.

Inspect cumulative reports separately. A correct individual period does not establish that year-to-date totals begin at the right date or that the opening balance comes from the right prior year. Trace the opening, period movements and closing balance using the same small test population.

Include a scheduled export or spreadsheet connection used by the company. Confirm that it receives actual fiscal identifiers and dates rather than reconstructing periods from calendar-month numbers. If a downstream tool maintains its own calendar, assign responsibility for keeping that mapping aligned with the ledger.

Ask an internal administrator to create the next calendar using the proposed procedure. This reveals whether setup is a routine task, a consultant service or a customization. Check the available review step before future dates become fixed by a year-close action.

Demonstrate how calendar corrections are handled before use and after transactions exist. The vendor should explain what is supported, what history is retained and which reports might change. Do not accept a method that casually rewrites historical period definitions without identifying the effect on previously issued reports.

Test a company with a different year-end if the implementation covers several legal entities. Verify the entity context on each setup screen and report. A shared group report may need a separate mapping, and the product's multi-company capability does not by itself establish that this mapping is maintained correctly.

Give the controller the completed calendar, boundary transactions and comparison outputs to review together. A screenshot of twelve period names is weak acceptance evidence. A reproducible set of dated postings shows what the configuration actually does.

Put any special calendar logic, reporting extension or annual maintenance task into the implementation scope. Identify who will update it, how a software release affects it and which reports need a targeted recheck after a change. Include relevant training for the ordinary finance administrator.

Resolve failures according to their consequence. An incorrect period assignment or misleading year comparison may prevent acceptance; a cosmetic caption can usually be handled separately. State the decision explicitly so the project does not treat every open item as equally important.

Accept the calendar when approved dates, posting controls and comparison logic produce the intended results across the difficult boundaries. The company should leave with a procedure it can repeat next year and an evidence set that explains why the present configuration was accepted.