Ledger Check — Controller Guide

An escalation is raised by a rail that knows it is unsure. A rail that is confidently wrong never escalates, so a quiet week says the rails have stopped asking — not that the books are right. Ledger check reads every entry since your last close, in full, and says what looks wrong. Nothing here posts, reverses or closes anything; a finding is a claim with the rows attached, and you decide.

For: controllers, CFOs and administrators · Time: ~10 minutes to read, a few minutes per run · You'll need: the Accounting module, an open period, and — for the reviewer half — a model key configured for your company under Admin.

How to access

Accounting → General Ledger → Journal Entries, then Check the ledger in the header, or /accounting/journal-entries/check. The page is titled Ledger check.

Part 1 — Two readers, one ledger

Every run puts the same rows in front of two readers.

The checks are the handful of things a ledger must never do, asserted mechanically every time and never skipped:

• a document that does not balance;
• a posting to a deactivated account, or to a roll-up account that other accounts sit beneath;
• a posting tagged to an undeclared entity your company's configuration does not list;
• an entry dated outside its period by more than a month;
• a native posting whose source record is missing, so nothing can say why it was booked;
• one counterparty and one amount that arrived through two rails — the shape of one event booked twice.

The reviewer reads the whole open period the way a controller does with everything in one place: every document with every leg, and the closed months before it laid out the same way, so trend and repetition are visible together. It looks for the same thing treated two ways, anything off its history, duplicates, and whatever else looks wrong. It is handed the documents and nothing else; every finding cites the entries it rests on, and a cite it cannot back is dropped rather than shown.

Labor appears at the ledger's own presentation grain — one document per pay period and project — never as timesheet lines. What you read here is what the General Ledger report shows.

Part 2 — Running a read

Read the ledger starts a run. Before the first run the page shows the Not read yet panel, headed Nothing has been read yet, and says exactly what a read would cover: the open month or months since your last close, and the closed months that will sit beside them. If nothing is open — the latest close is this month — the button is disabled and the reason is shown in its place.

The checks land in seconds. The reviewer takes a few minutes, and the page follows the run in; you can leave and come back. Read it again repeats a run. A finding the last run already raised is refreshed, not raised a second time, so nothing you answered comes back unless the rows change.

If a read cannot start, the message says why. A run that stops before it finishes says so where the findings would be — its own note, or The read did not finish — rather than leaving an empty list; read it again.

The strip

When a run has finished, the strip at the top — What was read — says what happened:

• Read — the open period read, and the closed months beside it.
• Documents — how many the open period held, how many in all across every period read, and how many accounts they touched.
• Checks — how many ran and whether any raised a finding.
• Reviewer — what it raised, and what the read cost in tokens against your company's model key.

Beneath the strip is one sentence on the reviewer's outcome in plain words: it read everything and raised so many findings; no reviewer is configured and the checks stand alone; it declined, was cut short, or answered badly and only the checks stand. Each of those is said as it is, never as an empty page.

Part 3 — Answering a finding

Findings that still need an answer come first, under findings to answer. Each card carries:

• the kind — Does not balance, Deactivated account, Roll-up account, Undeclared entity, Dated outside its period, Source record missing, Arrived through two rails from the checks; Treated two ways, Off its history, Duplicate or Looks wrong from the reviewer;
• who raised it — Check or Reviewer;
• the account a person would file it under, and the amount at issue;
• the headline and the sentence that makes it a discrepancy;
• the entries cited, each a chip; a journal entry opens on click, and a native batch or labor document names itself so you can find it in the General Ledger report;
• Check: the most useful thing to open or verify next.

A reviewer finding that cites no entry says so — read it as a lead rather than a fact.

Three answers, and every one is recorded with who gave it and when:

• Expected — it is right as booked. The finding retires until it changes.
• Fixing it — it is wrong and being corrected. It stays open so nobody loses it while the correction lands.
• Dismiss — it is not a discrepancy. A reason is required; type why into Why this is not a discrepancy and press Dismiss with reason, or Keep it to change your mind.

Answered findings fold away beneath the open ones under findings answered, with the answer and its reason shown; they are never deleted. Each card says how it was answered — Marked expected, Being fixed or Dismissed — by whom and when, with the reason quoted. When every finding of a finished read has an answer, or it raised none, the open list says exactly that.

Part 4 — What came back clean

The last section lists, in one sentence each, the areas each reader looked at and found consistent — every document balances, every native posting still has its source record, payroll consistent with the prior months, and so on. It is there so a short list of findings means what it says.

When the reviewer is not there

With no model key configured for your company, a read runs the checks alone and both the page and the strip say so. A read the reviewer declined, cut short or answered badly is said plainly beside the checks; run it again.