Month-End Accounting Close

Month-end is an ordered review of current resources, journals, reports, and statements. There is no mutation that performs the entire close. The final books-closing request only moves the first open date; it does not complete syncs, reconcile cash, repair issues, or publish statements.

Fix the Review Window

Choose the accounting month and keep its exact filters through every drilldown:

• period start and end, using an end-exclusive boundary where the operation declares one;
• as-of date for balance reports;
• currency and ledger;
• listing, effective parent listing, and ownership period; and
• owner or manager view.

Compare reports only when their scopes answer the same question. A trial balance for both ledgers, a trust-only reconciliation, and an owner statement are related views, not interchangeable totals.

Close Sequence

1. Settle Connection Work

Read GET /connections and inspect each source's status, accounting window, isErrorState, and currentSync. Then read the relevant sync and its changes. An active connection or accepted sync request does not mean extraction and canonical-resource updates are complete.

Do not start the accounting review while an in-scope source is still running, failed, awaiting reconnect, or outside the intended accounting window. Use the app's returned extractor capabilities when requesting additional work.

2. Reconcile Cash Activity

Read the applicable bank accounts and GET /accounts/{id}/summary?dateRange=..., then inspect GET /bank-records for unmatched, excluded, or otherwise unresolved records. Reconciliation links a bank record to a transaction; it does not create the missing balanced transaction for the client.

Create or correct the actual deposit, expense, transfer, payout, or refund, then reconcile the exact transaction. Preserve bank-record date and source identity when opening journal detail.

3. Review Guest Balances and Current Issues

Use GET /reports/guest-balances with the month-end as-of date to find guest or channel receivables that remain open. A balance can reflect charge, payment, refund, cancellation, and recognition events on different dates, so follow the returned reservation and transaction sources before correcting it.

Read GET /teams/issues?view=detail for the current team snapshot. Treat issue code, severity, feature, and context as the contract; do not parse its message. After a repair, re-read until computedAt advances instead of assuming the mutation synchronously refreshed portfolio health.

4. Verify the General Ledger and Trust Position

Use these server-calculated reports for distinct controls:

Keep the originating filters when following a report drilldown. Do not post an unrelated balancing transaction to hide a trust surplus or deficit; first find the missing cash, guest advance, owner balance, tax, payable, or attribution.

5. Review and Finalize Statements

Create or refresh draft statement resources for every ownership period, month, and currency in scope. A mid-month ownership change can require several statements for one listing. Render the returned layout, totals, sources, drilldowns, and issues in the requested owner or manager view.

Resolve error-severity statement issues before moving a statement to inReview or published; the API blocks those transitions. Warnings can require review without being a universal publishing blocker. Moving out of draft attaches eligible owner-side journal entries and establishes its period lock, so perform source corrections first.

6. Preview and Record Payouts

Call POST /statements/pay/preview with the intended owner selections and payout date. Show its blocking reasons and warnings, then call POST /statements/pay only after the preflight is acceptable.

The payout is a new dated transaction. It can post in the following month while remaining linked to the statement it pays. Do not move the statement month or rewrite its ending balance to make it match the payout date.

Payout execution is not a prerequisite for closing the statement month unless your operating policy makes it one. Its own journal date must remain open.

7. Move the First Open Date

After the in-scope review and corrections are complete, call PUT /team/books-closing. Send the first date that must remain editable, not the last date being closed. For a July close, the boundary is August 1:

PUT /team/books-closing
Content-Type: application/json

{
  "booksClosedAt": "2026-08-01"
}

Journal dates strictly before booksClosedAt become closed; the boundary date remains open. This operation has no dry run or preview. Require explicit confirmation, apply it once, and re-read the team before reporting completion.

Readiness Signals

Corrections After Review

Make corrections in an open period through the resource that owns the financial event. If a journal is attached to a statement, use the authorized statement lifecycle to return it to draft before changing eligible owner-side activity. If its journal date is before booksClosedAt, the books boundary is a hard lock.

Do not expose x-ignore-books-closed-at as a recovery control. It is reserved for controlled repair workflows and does not replace statement attachment or period-lock handling.

API Reference

• Connections — GET /connections
• GET /syncs, GET /syncs/{id}, and GET /syncs/{id}/changes
• Team issues — GET /teams/issues
• Trial balance — GET /reports/trial-balance
• Guest balances — GET /reports/guest-balances
• Trust reconciliation
• Journal entries — GET /reports/journal-entries
• Create statements — POST /statements
• Update statement status
• Pay owner statements
• Update books closing — PUT /team/books-closing

Related

• Accounting model
• Revenue recognition
• Reports
• Statements
• Accounting administration
• Connection health