The Authoritative Ledger: Real-Time GL, Consolidation & Inter-Company Elimination

Ask an accountant where the numbers really live and you often get an uncomfortable answer: it depends which report you opened. The transactional system has one version, the reporting database has another, and the group consolidation lives in a spreadsheet that someone rebuilds every quarter. Each copy drifts a little. LedgerQ is built on the opposite premise — one authoritative ledger that every business event posts to, and that every report reads from. There's no reporting copy to fall out of sync, because there is no reporting copy.

In summary: LedgerQ runs a real double-entry general ledger where posted GL lines are the single source of truth and reports read straight from them. Source documents auto-post, entries can't save unbalanced, and posting is segregated from approval. Group consolidation is native and gated: it reads each entity's real posted ledger, eliminates inter-company balances, translates currency, computes non-controlling interest, and refuses to publish a consolidation that doesn't balance.

What does "single source of truth" actually mean for a ledger?

LedgerQ runs a complete double-entry accounting system with the controls of a real book of record. The chart of accounts is hierarchical, and account assignments carry the classification that lets financial statements roll up correctly without hand-mapping every account.

The important part is the wiring. Journal entries are balance-enforced: an entry that doesn't balance to the cent can't be saved or posted, and the ledger layer re-verifies balance independently before it writes — so the books stay balanced by construction, not by discipline. And there's a subtlety most systems get wrong: in LedgerQ, the posted GL document lines are the authoritative ledger of record, while journal-entry totals are a derived cache. Posting is written so that a failure in a cache or a mirror can never block or corrupt the committed ledger. The number the bank sees and the number your bookkeeper closes are the same number, because they're read from the same posted lines.

The payoff is conceptual but it matters every single day: reconciling "the system" against "the reports" stops being a task, because they were never two things. That's the same guarantee your AI CFO relies on when Sebee answers a question or drafts an entry — it reads the authoritative ledger, not a snapshot that might have drifted.

How does a transaction reach the ledger without someone coding it by hand?

The tedious part of a ledger is deciding which accounts to debit and credit for every kind of event. LedgerQ automates that with GL Account Assignments: each transaction type is mapped to the right accounts once, so sales invoices, payments, and stock movements post themselves to the correct accounts — no operator picking accounts entry by entry. On top of auto-posting sit the controls that keep a real ledger honest:

• Approve-then-post, with segregation of duties. Posting is a distinct, permission-gated step, and an entry's own creator can't post it — the SoD control that PH CAS books (and any serious auditor) expect.
• Amount-tiered approval routing. A posting-rules engine routes high-value entries to the right approval level and blocks posting until the matching authority signs off. A ₱2,000 reclass and a ₱2,000,000 accrual don't get the same scrutiny.
• Recurring journal entries. Define an accrual or standard entry once and let it generate on schedule, with catch-up, pause, and resume — instead of re-keying it every period.
• Validation-gated period close. Posting respects open-period constraints, and the close runs pre-close validations that block a close from starting on critical failures — with reopen and entry reversal supported when something has to be undone cleanly.

Everything above is real double-entry plumbing, described in more depth on the general ledger module page. The result is a ledger where the accounting is enforced in code, not left to a policy nobody reads.

Why is consolidating a group the harder problem?

A single company on one authoritative ledger is already valuable. But most real businesses aren't a single company. They're a group — a parent and its subsidiaries, often in different currencies, frequently trading with each other. Reporting on that group is where a lot of accounting software quietly gives up and hands the work back to a spreadsheet.

LedgerQ models the group as a first-class structure — an Organization over Company hierarchy with ownership percentages — rather than something you simulate with tags. A consolidation run then reads each entity's real posted GL documents (its trial balance, income statement, and balance sheet come from actual posted ledgers, not a re-keyed summary or a mock feed) and does three genuinely hard things:

1. Eliminate inter-company balances. When one entity in the group sells to another, both sides book the transaction — but from the group's point of view, the group sold to itself, and that revenue and expense have to disappear. LedgerQ builds AR/AP and revenue/expense eliminations from the real inter-company transactions you recorded, translates them to the group currency, and writes them as balanced journals. You're not hunting across two sets of books to match one entity's receivable against the other's payable — both ends are tracked and cancelled.

2. Translate currency. A subsidiary that keeps its books in one currency has to be expressed in the group's reporting currency before it can be added up. Currency translation to a single reporting currency is built into the consolidation run, so an FX difference doesn't quietly distort the consolidated result.

3. Compute non-controlling interest. When the parent owns less than all of a subsidiary, the slice that belongs to outside shareholders has to be carved out. A minority-interest calculator posts balanced NCI journals per subsidiary, resolved through account assignments — and it fails closed on gaps rather than guessing, so the group's equity correctly reflects who actually owns what.

What stops a broken consolidation from being published?

This is the difference that should decide the buy. In LedgerQ, a consolidation run is a real workflow — aggregate, translate, eliminate, compute NCI, validate, persist — executed inside an atomic transaction with per-period locking. And it ends with a hard gate:

If assets don't equal liabilities plus equity plus NCI, the run rolls back and the period is marked failed. A non-balancing consolidation is never reported as success.

That refusal to fake a result runs all the way down. Where an advanced elimination isn't fully automated, the system raises an explicit error rather than silently returning a wrong or zero number — you get a consolidation you can trust, or a clear reason you can't. Inter-company transactions add one more guard: each side records its approval independently, and a superuser bypass is explicitly denied, so value can't be pushed onto a sister entity's books on one-sided sign-off. The controls here are cousins of the platform-wide security posture — fail-closed, attributable, and enforced rather than documented.

Is it really real-time, or just faster?

Here's the contrast that defines the feature. In many systems consolidation is an event: at quarter-end someone exports trial balances, drops them in a workbook, keys the eliminations by hand, applies FX rates manually, calculates NCI, and produces a group statement that's already days old by the time it's reviewed. It's slow, error-prone, and it only exists at the moments someone builds it.

In LedgerQ, consolidation is a property of the ledger. Because each entity's numbers come from its live posted GL and the elimination, translation, and NCI steps are computed by the engine, the group can run a consolidation for a period and see a consolidated balance sheet, P&L, and cash flow built from the same authoritative ledgers as every other report — not a separate group copy that drifts. Multi-currency subsidiaries feed the same run; if FX is a big part of your picture, the mechanics of multi-currency and translation are worth reading alongside this.

How does this change the month-end close?

For a multi-entity group, the close is usually dominated by the consolidation grind — chasing inter-company mismatches, re-keying FX, patching the spreadsheet that breaks when a new subsidiary is added. When elimination, translation, and NCI run against real posted ledgers behind a balance-sheet gate, that grind largely evaporates. The group statements aren't reconstructed under deadline; they're produced from the ledger and validated before they're trusted. Closing the books becomes reviewing numbers the system assembled and checked, instead of assembling them from scratch and hoping they tie. A single source of truth is good hygiene for one company — for a group, making it real-time, gated, and consolidated is what turns the close from a reconstruction project back into a review. (For the reporting side of that close, see period close and reporting.)

Frequently asked questions

Does LedgerQ keep a separate reporting database from the general ledger? No. Posted GL document lines are the single authoritative ledger of record, and reports read directly from them — journal-entry totals are just a derived cache. There's no reporting copy to fall out of sync, so the balance sheet you show the bank and the trial balance your bookkeeper closes are the same numbers.

How does LedgerQ eliminate inter-company transactions during consolidation? It builds AR/AP and revenue/expense eliminations from the real inter-company transactions recorded between entities, translates them to the group's reporting currency, and writes them as balanced journals. Each inter-company transaction is approved by both sides independently, and a superuser can't bypass that dual approval.

What happens if a consolidation doesn't balance? The run fails closed. A consolidation executes inside an atomic transaction, and if assets don't equal liabilities plus equity plus non-controlling interest, it rolls back and the period is marked failed — a non-balancing consolidation is never reported as success. Where an advanced elimination isn't fully automated, the engine raises an explicit error instead of returning a wrong or zero figure.

Is consolidation real-time or a periodic batch? A consolidation run reads each entity's live posted GL — its real trial balance, income statement, and balance sheet — so you can produce a consolidated balance sheet, P&L, and cash flow for a period from current ledger data rather than a quarter-old spreadsheet. It's generated from the same authoritative ledgers as every other report.

Can source documents post to the ledger automatically? Yes. GL Account Assignments map each transaction type to the right accounts, so sales invoices, payments, and stock movements post themselves without an operator choosing accounts per entry. Entries still can't save unbalanced, posting is segregated from approval, and high-value entries route through tiered approval before they post.