Chapter 5.10 — Period Close

1. Purpose

Period close is the controlled transition of an accounting period (typically a calendar month) from Open to Closed (and, after audit sign-off, Locked). This chapter defines the close mechanics: state machine, required pre-close activities, reconciliation gates, the close run itself, post-close adjustments handling, and the audit-lock state. The discipline of period close is what turns an operational system into a financial system.

2. Why it matters in modern travel accounting

Without disciplined period close: - Bookings creep into wrong months (service-date drift, late entries) - Restated financials damage credibility with banks/investors - Audit fees inflate as accountants chase moving numbers - Comparative reporting (month-over-month, YoY) becomes meaningless - Tax filings risk amendment penalties

Travel-specific drivers: - BSP semi-monthly settlement crosses month boundaries - Service dates ≠ issuance dates by weeks or months - Refunds and ADMs land months after the original booking

3. Industry relevance

travoBooks' period-close model aligns with standard ERP practice (Oracle, SAP, NetSuite, QuickBooks) while accommodating travel-industry quirks: BSP cut-off, deferred revenue recognition, ADM provisioning, commission true-ups.

4. Compliance considerations

• IFRS 15 — period-end revenue recognition run (Chapter 5.7) is mandatory at close.
• IAS 21 — FX revaluation of monetary balances at period-end closing rate (Chapter 5.6).
• IAS 1 — Presentation — comparable periods, consistent classification.
• SOC 2 / ISO 27001 — change-control over close, segregation of duties (maker vs checker for close itself).
• Tax filings — many jurisdictions require monthly VAT returns based on closed-period numbers.

5. Business logic

5.1 Period states

5.2 Pre-close checklist (per partner per period)

Before initiating close, the platform validates a configurable checklist:

Unsatisfied items block the soft-close transition (the gate).

5.3 Soft-close

Soft-close moves period to SoftClosed: - Bookings with transaction_date in period cannot be edited. - New JEs into the period require period_admin permission. - Operational entries (new bookings, payments) into the period are blocked; current-period operations continue.

This window allows the accountant to make month-end adjustments without operational noise. Typical duration: 3–10 business days.

5.4 Close

After all adjustments are in: 1. Final trial balance generated and saved as a financial record. 2. Final P&L, Balance Sheet, Cash Flow generated and snapshotted. 3. Period transitions to Closed. 4. All postings into the period now require a Reopen workflow. 5. Notifications to partner_admin + controller + audit role.

The close itself is maker-checker: one user initiates, another approves.

5.5 Post-close adjustments

If a discovery requires posting into a closed period: 1. Operator initiates Reopen Request with justification and impact summary. 2. Controller-level approval required. 3. Approval moves period back to SoftClosed. 4. Adjustment posted with is_post_close_adjustment = TRUE flag. 5. Period re-closed with new trial balance snapshot. 6. Audit trail captures the full reopen → adjust → re-close cycle.

Most platforms prefer to post the adjustment in the current period with appropriate disclosure rather than reopen — travoBooks supports both paths, with current-period preferred by default.

5.6 Lock

After external audit completes: - Auditor (or platform admin) marks period Locked. - No further changes possible by any role. - Any future correction must use a prior-period adjustment in a current open period, properly disclosed.

5.7 Year-end close

At fiscal year-end, additional steps: 1. Income statement accounts closed to retained earnings:

Debit  Revenue Accounts (4xxx) — total                  Σ
Credit COGS/Expense Accounts (5xxx/6xxx) — total        Σ
Credit/Debit Retained Earnings (3001)                   net income/loss

1. New fiscal year periods initialised.
2. Annual financial statements snapshotted.
3. Audit pack generated.

The year-end close is a special close workflow with additional pre-checks (full-year recognition complete, year-end accruals booked, tax provisions estimated).

5.8 BSP-period vs accounting-period

BSP settles on semi-monthly periods that may not align with calendar months. The platform handles this by: - Recording every transaction with both accounting_period and bsp_period dimensions. - BSP files are imported into the bsp_period they belong to. - The Bank/BSP reconciliation matches by bsp_period. - The accounting close uses calendar month; BSP settlement may straddle.

If a BSP file for a period ending in the current accounting month has not yet arrived, the close can still proceed with estimated BSP-payable accrual (based on issued tickets), trued-up when the file arrives.

6. Inputs → processing → outputs

Initiate soft-close

Input: {partner_id, period_year, period_month}

Processing: 1. Permission check (period.close.partner). 2. Run pre-close checklist. 3. If gate failed → return list of unsatisfied items. 4. If gate passed → set period_state = SoftClosed, record initiator. 5. Notify accountants.

Output: Close-readiness report + state transition.

Final close

Input: {partner_id, period_year, period_month} from SoftClosed state.

Processing: 1. Permission check (period.close.approve.partner — must differ from initiator). 2. Trigger recognition run, FX revaluation, accrual run. 3. Generate trial balance. 4. Validate SUM(Debits) = SUM(Credits) exactly. 5. Generate P&L, BS, CF snapshots. 6. Set period_state = Closed. 7. Lock postings. 8. Notify stakeholders.

Output: Snapshot files (PDF + structured data) attached to period record.

7. Module dependencies

8. Security & permissions

9. Validation rules

10. Error handling

A failed final close (e.g., trial balance doesn't balance) leaves the period in SoftClosed; the system surfaces the unbalanced account(s) and refuses to proceed. This is the strongest invariant in the platform.

11. Real-world examples

A — Routine monthly close

May 2026 close timeline: - May 31 — operational month-end. - Jun 1–3 — accountants finalise bank recon, BSP recon, AR/AP review. - Jun 4 — recognition + FX revaluation runs. - Jun 5 — soft-close initiated by accountant. - Jun 5–7 — controller reviews snapshots, drills into anomalies. - Jun 8 — final close approved by controller; period closed. - Jul 15 — auditor reviews (quarterly cycle); locks Q1 (Mar 31) after sign-off.

B — Post-close discovery

Mid-Jun: accountant discovers a missed ADM acceptance from May, BDT 18,000. - Option A (preferred): post in June with disclosure "ADM related to May ticket issuance". - Option B: reopen May, post, re-close — requires controller approval and additional audit attention.

C — Year-end close

December 31 close adds: - Final-quarter accruals (bonus, annual override, tax provisions). - Closing entries to retained earnings. - Comparative-prior-year snapshot. - Year-end audit pack export.

12. Step-by-step workflow

13. Database tables touched

14. Future scalability

• Continuous close — automated reconciliation reduces formal close to confirmation only.
• Auditor portal — auditors get scoped read-only access during their review.
• Predictive close-readiness — ML flags likely close-blocking issues 5 days before month-end.
• Period-close orchestration UI — Kanban-style board for the close runbook with task ownership.

15. Common pitfalls

• ⚠️ Closing before recognition run. Revenue lands in the wrong period; restate.
• ⚠️ Skipping the pre-close gate. Bookings in DRAFT in a closing month indicate either data loss or unfinished work; investigate.
• ⚠️ Same-user close. Maker-checker is mandatory; bypassing destroys audit credibility.
• ⚠️ Reopening when current-period adjustment would suffice. Reopen is a last resort.
• 🔒 Lock requires audit attestation. Don't lock as a convenience — locked is forever (without platform admin override).
• ⚠️ BSP semi-monthly period crossing month-end can produce timing differences between BSP-payable accrual and BSP-statement matching. Document this in period notes.