How do I catch backdated entries posted into a closed month after month-end close?

What should I check, step by step?

1. Lock the month in the accounting software once it's reconciled (QuickBooks Online Close the books with a password, or a Xero lock date) and keep the password or administrator role away from day-to-day entry.

2. Seal the business's records into a mirror ledger as they happen (invoice, payment, adjustment, tip_allocation, tip_payout, dispute_note), with occurred_at set to the business date. Don't batch-seal a whole month at close, or every entry will look post-close.
3. At close, record the close head: the seq and entry_hash of the last entry sealed for that month, and the time you recorded them. Send it to your accountant or put it in the close memo, so a copy sits outside the business.
4. Book corrections to a closed month as new adjustment entries dated in the open month, with a note pointing at the original entry id. The mirror has no edit or delete route, so a correction is always a new entry.
5. At review time, list the entries (owner key) and flag every entry whose occurred_at falls inside a closed month but whose seq is after that month's close head. Those are the backdated or post-close entries to explain.
6. Check that the close head still holds: the entry at that seq must still have the same entry_hash, and GET /v1/mirror-entries/{id} must report chain_valid true. A different hash means history up to the close was changed.
7. Compare with the accounting software: pull the QuickBooks Online audit log (or Xero History and notes) for changes made after the close date to transactions dated in the closed month, and match each one to a mirror adjustment entry.
8. Keep the close heads, the mirror entry ids and the exported reports for as long as your tax records. QuickBooks Online's audit log only keeps events for two years.

Why doesn't a lock date alone catch backdated entries in a closed month?

QuickBooks Online's Close the books setting protects transactions dated on or before the closing date with a warning or a password. In Xero, only an administrator can set lock dates, and administrators can remove them to make changes. Both are controls run by someone inside the business.

• A backdated entry carries a transaction date inside the closed month, so a report run for that month includes it as if it had always been there. What gives it away is when it was recorded, and that time has to come from somewhere the person posting it can't change.
• PCAOB AS 2401 lists entries recorded at the end of the period or as post-closing entries with little or no explanation among the typical marks of inappropriate journal entries, and says fraudulent entries are often made at the end of a reporting period. It's written for audits of public companies, but it's a useful checklist for any reviewer of a small business's books.

How do two dates and a close head expose entries posted after month-end close?

Each mirror entry stores occurred_at, the date the business gives, and sealed_at, which Rightshold sets when the entry arrives. Entries are numbered in order (seq). Each entry_hash covers the ledger id, seq, type, occurred_at, a SHA-256 of the content and the previous entry's hash, so changing any earlier entry changes every hash after it.

• Each entry is also written to Rightshold's append-only public ledger, whose blocks are timestamped in Bitcoin through OpenTimestamps. That ties sealed_at to a block anyone can check with ledger_verify and ledger_anchor, without an account.
• The close head (seq plus entry_hash at close) is the line in the sand. Entries after it were recorded after close, whatever date they claim. Entries before it can't be changed without the chain failing against the hash your accountant already holds.

What can an accountant check about post-close entries without logging into the books?

With an entry id, anyone can call GET /v1/mirror-entries/{id} for free: the record as sealed, occurred_at and sealed_at, its chain check and its anchor status. GET /v1/mirror-ledgers/{id} shows the neutral label, the entry count by type and the first and last seal times.

• Given the close head and the owner's entry list, the reviewer can test three things: the close-head entry still has the recorded hash, the chain is valid, and every entry dated in the closed month with a later seq has a matching, explained adjustment.
• This finds post-close entries that were sealed. It can't see an entry that was posted in the accounting software and never sealed, so match the software's audit log against the mirror in both directions.