General Ledger Software: How Controllers Should Evaluate the Ledger Layer

Search results for general ledger software put unlike products in one list. A ledger module inside an ERP, a small-business accounting system and a specialist multi-entity platform all answer to the same phrase while placing very different limits on how a company records, dimensions, closes and evidences its accounts.

This guide treats the choice as a ledger-capability decision rather than a feature contest. It sets out what the ledger layer must do for a controller, the documented constraints that decide whether a product can carry a company’s reporting, and a test script a shortlist should survive. The product map was checked against official documentation on 20 August 2026.

What general ledger software actually means

General ledger software holds the chart of accounts, accepts and posts journal entries, controls accounting periods and produces the trial balance from which financial statements are built. It is a layer, not a product category. Almost every accounting product contains one, which is why the phrase covers everything from a bookkeeping tool to the core of an ERP.

The classes are not a maturity ladder. A single-entity company with heavy management reporting may need dimensional depth an entry product cannot supply, while a larger group with simple structures may run comfortably on a mid-market platform. Where operational records stop and accounting records begin belongs to the wider question of where the boundary between accounting software and ERP should sit, and the ledger’s place among neighbouring systems is clearer against a reference architecture for the finance stack.

The chart of accounts and the dimension decision

The most consequential design choice in a ledger is what belongs in the account code and what belongs in a dimension. A natural account answers what happened: revenue, salaries, depreciation. A dimension answers where, who and why: entity, department, cost centre, product, project, fund, customer.

Without usable dimensions the account code absorbs the work. Companies create parallel account ranges per department or location, and the chart grows into thousands of accounts that are hard to maintain, hard to map at consolidation and hard to change. A bloated chart of accounts is usually a symptom of missing dimensional capability rather than of complexity in the business.

The published limits are specific and worth reading before a demonstration. Microsoft documents Dynamics 365 Business Central as supporting exactly two global dimensions and up to eight shortcut dimensions, and warns that changing one is not a configuration tweak: the Business Central dimensions documentation states that changing a global or shortcut dimension requires all entries posted with it to be updated, and advises choosing carefully to avoid changing them later. SoftLedger documents cost centres, products and jobs alongside up to three custom dimensions. Flexi documents a user-defined account key that extends to 60-position accounts.

At the entry tier the constraint is a subscription limit rather than a design decision. Intuit publishes usage limits by plan: Simple Start and Essentials do not offer classes and locations at all, Plus allows 40 combined, and Advanced removes the limit. The QuickBooks Online usage limits page also caps the chart of accounts at 250 accounts below Advanced, and states that reaching a limit blocks new items until the subscription is upgraded or usage reduced. Those numbers decide whether a reporting requirement is achievable, before implementation begins.

Three questions settle the design:

• Which reporting cuts must come from posted data, and how many dimensions does that need at once?
• Which dimensions are mandatory on posting? One that is optional at entry will be incomplete in reporting.
• What does the product require to add, retire or restructure a dimension once entries exist?

Journals, approval and the entries an auditor will select

Journal control is where a ledger either supports the audit or creates work for it. Auditors do not sample journals at their discretion. PCAOB Auditing Standard 2401 requires the auditor to design procedures to test the appropriateness of journal entries recorded in the general ledger and other adjustments, because manipulating the reporting process through inappropriate entries is a recurring feature of financial statement fraud. The standard also directs the auditor to understand controls over initiating, authorising, recording and processing entries, and to separate recurring standard entries from non-standard ones that may not pass the same controls.

That has a direct product consequence. The ledger must produce the complete population of entries for a period, not a filtered report of those an administrator chose to expose. PCAOB staff identify failure to test completeness of the journal entry population as a recurring inspection finding in Audit Focus: Journal Entries. When the ledger cannot evidence completeness, the audit team resolves it with additional procedures and the cost lands on the company.

What a journal export must contain

Ask for a sample export from a live tenant rather than a specification sheet. A usable population carries entry and line identifiers, posting date and period, account and dimension values, debit and credit amounts with currency, the entering and approving user, the timestamp, the source module, whether the entry was manual or system-generated, the reversal linkage, and any attached support. The manual or system-generated flag is the one worth pressing on, because system-generated entries carry their own evidence burden that a posting user and timestamp alone do not discharge.

Approval behaviour matters as much as the record. NetSuite documents journal approval workflows verifying criteria such as threshold amount and approval limits before the journal is posted. The test is whether approval is enforced by the ledger or applied in a surrounding tool, because only the first survives a change of process owner.

Correction method is the third element. A ledger that allows a posted entry to be edited or deleted loses the history an auditor needs. Acumatica documents the stricter position in its general ledger documentation, stating that it maintains a complete audit trail and that entries cannot be deleted. Reversal preserves the record; editing in place does not.

Periods, calendars and close control

Period control decides whether a reported number can change after it has been reported. Separate two behaviours during evaluation. A soft close prevents ordinary users from posting into a period while allowing named roles to continue. A hard close prevents posting entirely and requires an explicit, logged action to reverse.

Neither position is automatically right. Acumatica documents that periods can be kept open as long as data entry requires, which suits teams that post late and reconcile continuously; tighter regimes lock on a fixed date and push adjustments into the following period. Establish which roles can reopen a closed period, whether reopening is logged with a reason, and whether reports rerun afterwards silently change previously distributed figures.

Calendar structure is the related question. A ledger supporting only calendar months will not serve a 4-4-5 retail calendar, or a company whose statutory and management calendars differ. Where two accounting bases must coexist, some products maintain parallel books rather than adjusting entries: NetSuite documents a multi-book engine recording book-specific activity from a single transaction, covering revenue recognition, amortisation, depreciation and allocations. Sequencing the tasks around these controls belongs to the control-first close checklist.

Subledger posting and agreement to the control account

Most transactions do not originate in the ledger. Payables, receivables, payroll, inventory, fixed assets and revenue arrive from subledgers, and the posting model decides what can later be reconciled and explained.

Summary posting sends a period total to the control account; detail posting sends transaction-level entries. Summary posting keeps the ledger small and fast, but a query about a balance then needs the subledger, and any difference between the populations must be investigated outside the ledger. Detail posting puts the evidence in one system at the cost of volume. The choice must be deliberate, because it determines what a reconciliation can prove.

Three checks separate a working integration from a documented one:

• What posting means. Generating a file, calling an interface and receiving final ledger acceptance are three states. Only the last proves the entry reached the books.
• Whether the control account is protected. One that accepts manual journals will drift from its subledger, and the difference surfaces at close rather than at entry.
• What happens to a rejected entry. A ledger that rejects an interfaced batch without an owned exception queue creates a silent gap between the two systems.

Responsibility for the resulting reconciliations sits outside the product decision. Ownership, evidence and exception-handling standards are set out in the guide to reconciliation ownership and evidence, and the interfaces carrying these postings are easier to assess against a documented map of finance system data flows.

Multi-entity, multi-currency and consolidation readiness

Group reporting is where ledger capability is most often overestimated. Under 17 CFR 210.3A-02, registrants consolidate majority-owned entities and do not consolidate others, on the basis that consolidated statements are usually necessary for fair presentation. Whatever the framework, a group with subsidiaries must produce a consolidated result, and the ledger either supports that or exports the problem to a spreadsheet.

Four capabilities decide the answer:

• Entity structure. Whether entities are separate ledgers, separate books or a dimension value, and whether ownership percentages can be held and applied.
• Currency handling. Whether the ledger distinguishes transaction, functional and reporting currency, and where translation differences post.
• Intercompany posting. Whether a transaction between two entities creates balanced entries in both, and whether the pairing survives a correction.
• Elimination. Whether elimination entries sit apart from the operating books, so entity results stay reportable after the group result is produced.

Several mid-market products document this within the ledger: Flexi states unlimited companies with intercompany rules and automated eliminations, Sage describes Sage Intacct as consolidating entities across currencies and geographies with multi-dimensional reporting and multi-entity consolidation, and NetSuite documents consolidation under multiple accounting standards. These are company-stated capabilities describing what the product offers, not how it will behave on a specific group structure.

The boundary is worth stating. A ledger that consolidates well may still not perform ownership calculations for partly owned entities, statutory adjustments differing from group policy, or the disclosure workflows group reporting requires. Where those exist, a separate consolidation layer above the ledger is the right design, and the ledger’s job becomes clean, dimensioned, entity-tagged data.

Audit trail, access and hosted-ledger evidence

Three control questions apply to any ledger. Immutability: posted entries should not be editable or deletable, and the record of who did what should not be clearable by an administrator. Segregation of duties: whether the product prevents one person creating, approving and posting an entry. Change control over the configuration, because the chart of accounts, dimension structure, posting rules and approval thresholds are as material as the entries they govern.

A fourth applies to cloud ledgers. PCAOB Auditing Standard 2601 treats a service organisation’s services as part of the user entity’s information system where they affect significant classes of transactions and the financial reporting process, and gives the auditor two routes: test the user organisation’s own controls, or obtain a service auditor’s report. It also separates a report on controls placed in operation, addressing design at a point in time, from one covering operating effectiveness over a specified period.

So request the provider’s current service auditor report, confirm it covers operating effectiveness rather than design alone, check the period matches the financial year, and read the complementary user entity controls. Those are the controls the provider assumes the company operates, and they remain the buyer’s responsibility whatever the report concludes.

Representative general ledger products checked 20 August 2026

Products were included when US-relevant official documentation showed a general ledger with at least four of: a configurable chart of accounts, user-defined dimensions or segments, journal approval or workflow, period open and close control, subledger integration, and multi-entity or multi-currency operation. Bookkeeping-only tools, reporting layers above a ledger, single-profession products, and products without enough public official material were excluded.

The table is not a ranking. Products are grouped by operating model and alphabetised within each group. Official pages establish company-stated availability, not comparative accuracy, control effectiveness or performance at another buyer’s volumes. Pricing is reported as visibility, not negotiated cost. Finance Circuit does not sell, resell or take placement fees for any product named here.

Absence is not a negative assessment. Several products ranking for this term were excluded only because their public pages did not document four of the six criteria, not because the product lacks the capability. Expand the shortlist for a required country, statutory regime or existing system estate not covered here.

Entry accounting systems with a built-in ledger

These give a complete accounting system quickly and cheaply, and their ledgers are genuine ledgers. What they do not give is dimensional depth or entity structure, and that constraint is published rather than negotiable. A company needing several simultaneous reporting dimensions, or holding a second entity, has usually already passed the boundary even when the close still works.

Financial management platforms with a dimensional ledger

This group exists because the gap between entry accounting and full ERP is where most multi-entity finance teams operate. The ledger is dimensional by design, entity structure is native, and consolidation and close sit in the same product. Establish how many user-defined dimensions the licence permits, which functions are separately priced, and what changing a dimension requires after posting.

ERP financials with a general ledger module

Here the ledger is the accounting core of a wider suite, and operational transactions and accounting share one data model. The risk is that ledger fit gets decided as a by-product of the suite decision. Score the ledger separately, on the same tests applied to every other candidate. The surrounding approval framework belongs to a finance-led ERP scorecard.

A test script for a general ledger shortlist

Documentation establishes what a vendor states. A scripted proof establishes what the product does with the company’s own data. Run the same script against every shortlisted product and keep the results, because they are the evidence behind the approval.

1. Load the real chart of accounts. Not a sample. Record whether it fits any account limit and what the product does with accounts it rejects.
2. Post a fully dimensioned journal. Use every dimension the business needs at once, and confirm reporting can filter on each one.
3. Attempt a prohibited posting. Post to a closed period, to a control account, and with a mandatory dimension blank. Record which are refused and what evidence each leaves.
4. Route a journal through approval. Confirm the creator cannot approve it, the threshold is enforced by the ledger rather than a surrounding tool, and the record survives a later correction.
5. Correct a posted entry. Establish whether correction is by reversal or edit, and whether the original remains visible with its original values.
6. Reconcile a subledger to its control account. Use a real month. Record whether the populations agree and where evidence is retained.
7. Export the complete journal population. Check the fields listed earlier are present, and agree it to the trial balance for the period.
8. Produce a consolidated trial balance. Use the real entity structure and two currencies. Record where translation differences post.
9. Change a dimension after posting. Ask the vendor to demonstrate it. This is the test most often skipped and the one most likely to constrain the company later.

Make the ledger decision

Apply pass-or-fail gates before any weighted score. A product leaves the shortlist when it cannot hold the required account and dimension structure, enforce period and approval controls, evidence a complete journal population, or carry the entity and currency structure the group reports on. None of those is offset by a strong demonstration elsewhere.

Then place the surviving decision in one of three positions. Reconfigure the current ledger when the gaps are design gaps: a chart of accounts doing dimensional work, dimensions left optional at entry, or approval running outside the system. Replace the accounting system when the constraint is published and structural, such as an account or dimension cap the reporting exceeds. Move the ledger into an ERP when the reason is the operational data model rather than the ledger, and the wider implementation is separately justified. The surrounding close tooling is a different question, addressed in the guide to comparing close platforms.

Keep the requirement list, test results, unresolved conditions and commercial scope as one record. Reopen the decision when entity structure, reporting obligations, volume or audit expectations change, because each moves the ledger requirement before anything else.