xMatix has a PeriodCloseService that can evaluate and store a close checklist, but the audited repository does not expose that service through a first-party Period Close handler, server action or workbench UI. The demo2 PeriodClose?create=1 form is therefore not evidence of a runnable evaluate-and-close procedure and is intentionally omitted.
The operational Fiscal Period handler separately exposes Close Period, Reopen Period and Lock Period. Those direct actions change period status without calling the checklist service. Posting validation currently accepts only Open, so neither Closed nor a nominal SoftClosed value is postable through the normal journal path.
Reconcile before changing the status
Complete and retain evidence for at least the checks implemented in the close service:
Mandatory checks:
- every posted journal balances;
- no Draft/unposted journal is dated in the period;
- AR/AP open items tie to their allocations; and
- no failed posting remains in the queue.
Advisory checks:
- GL and party balance caches agree with the ledger;
- bank reconciliations are completed;
- Employee Payable ties to open claims;
- Employee Advance ties to open advances;
- inventory NRV write-downs/reversals are posted; and
- per-book valuation overlays are current.
The service classifies four checks as mandatory and six as advisory. Because the current UI action does not invoke it, those classifications do not automatically block the direct Close Period action. Your close owner must run the equivalent reports and sign off the evidence outside the unexposed service until the workbench is wired.
Current procedure
Step 1 — Finish and reconcile the period
Post valid documents and journals, resolve failed postings, complete bank reconciliation and tie each control account to its supporting detail. Review expenses/advances and inventory valuation. Record report parameters, timestamps and totals so a later reviewer can reproduce the result.
Step 2 — Confirm the period is Open
Open the Fiscal Period record and verify its dates, fiscal year and current status. The journal posting validator requires exact status Open. A SoftClosed status is not a permissioned posting state in the audited path.
Step 3 — Close through the Fiscal Period action
After human approval, run Close Period on the exact Fiscal Period. This performs the direct Open-to-Closed transition. Reopen the record and verify Closed. Do not assume a PeriodClose header or checklist rows were generated; the direct action does not call PeriodCloseService.
Step 4 — Reopen only for an approved correction
If a valid late entry belongs in the period, use Reopen Period, make and verify the correction while the period is Open, repeat the entire reconciliation and close it again. Preserve the approval and both reconciliation snapshots.
Step 5 — Lock only after final sign-off
Use Lock Period after audit/filing policy says the period is final. Confirm downstream correction procedures before locking. Normal posting accepts only Open, and the lock action is not a substitute for the missing checklist integration.
Year-end
Fiscal Year has a separate Close Year action. Treat it as a distinct operation: verify the final period, retained-earnings account, generated journal and opening balances. Do not infer that closing an individual Fiscal Period automatically runs the year-end journal.
Common questions
Does Close Period automatically run the ten checks?
No. The checks exist in PeriodCloseService, but the current direct Fiscal Period action bypasses that service. Run and retain equivalent evidence manually until a first-party caller is implemented and tested.
Can a user post into SoftClosed with permission?
Not through the current journal validator. It requires exact Open status. There is also no first-party Soft Close action in the Fiscal Period handler.
What if something must post after close?
Obtain approval, reopen the period, post the correction, repeat reconciliation and close again. Do not change a document date merely to evade the intended period.