Insights · 14 min read
A single-entity general ledger runs $40,000 to $90,000; multi-entity consolidation pushes builds past $200,000. Here is what a ledger build involves and how to budget.
By GGP Editorial
The general ledger is the least glamorous part of accounting software and the part that fails first. Invoice screens and dashboards get all the attention in a demo. The ledger is a set of tables that either keeps every number in the company consistent, or quietly corrupts them. When a founder or a finance lead asks us about building accounting software, the ledger is where the real conversation starts.
I write this from the vendor side. GlobeSoft is a software company founded in 2018 with 40-plus engineers and more than 300 delivered projects. We have built financial systems for clients in Brazil, South Africa, Singapore and the US, including a financial management and accounting system covering accounts payable, accounts receivable, tax computation and real-time financial statements. This guide is for the people planning one of these builds: a founder adding accounting to a fintech or SaaS product, a CFO replacing a spreadsheet consolidation, or an ops team whose current ledger no longer handles multiple entities.
A general ledger, or GL, is the master record of every financial transaction in a company, organized by account. It is the source every financial statement is generated from.
Double-entry accounting sits underneath it. Every entry has a debit side and a credit side, and the two must balance. Sell something for $100 on credit and you debit accounts receivable $100 and credit revenue $100. That balancing rule is not a nice-to-have. It is the mechanism that keeps the books from drifting, and the software should enforce it at the database level, not just in the user interface.
A chart of accounts organizes the ledger into categories: assets, liabilities, equity, revenue and expenses. Below the GL sit sub-ledgers, which hold the detail. Accounts payable tracks what you owe suppliers. Accounts receivable tracks what customers owe you. Inventory, fixed assets and payroll are each their own sub-ledger in a fuller system. The sub-ledger keeps the line items; the GL carries a control account that summarizes them, and the two must tie.
From the ledger you produce a trial balance, a list of every account and its balance. Debits and credits should match. Then come the financial statements: balance sheet, income statement and cash flow. If the ledger is right, the statements are a rendering job. If the ledger is wrong, no amount of dashboard polish fixes the numbers.
Four profiles come up repeatedly.
A fintech or fintech-adjacent founder whose product needs a ledger inside it. Lending platforms, payment processors, wallets, marketplaces that hold balances, and trading systems all need to track money they owe, hold and move. For them the ledger is the product, not an internal tool.
A SaaS company embedding accounting or reporting for its own customers. They are not building QuickBooks. They are building the financial core their product runs on.
A multi-entity group outgrowing its current tool. This is the profile that usually finds us with a specific pain: the company has three, five or twelve legal entities across countries, and month-end consolidation happens in a spreadsheet that no one trusts. Their existing software handles single-entity books fine and falls apart the moment they need one set of consolidated statements.
An ops or finance team replacing a legacy system. The GL they run on is old, rigid, or tied to a product that is being retired, and the close takes too long because so much of it is manual.
A ledger build accumulates scope that buyers never use. The modules that decide whether the books are right form a smaller, harder set.
| Module | What it does | What to watch |
|---|---|---|
| Chart of accounts | Defines the account structure and coding | Plan segments and dimensions early; renaming a live account is painful |
| Double-entry engine | Posts balanced debits and credits | Enforce balance at the database level, not the UI |
| Journal entries | Manual and automated entries | Posted entries must be immutable; edits reverse, never overwrite |
| Sub-ledgers (AP/AR) | Detail for payables and receivables | Control accounts must tie to GL totals |
| Trial balance | Snapshot of every account balance | Should always balance; a silent soft-close hides real problems |
| Period close | Locks periods, posts accruals and adjustments | This is a workflow, not a date field |
| Financial statements | Balance sheet, P&L, cash flow | Generate from the ledger, never from a spreadsheet |
| Multi-entity consolidation | Rolls subsidiaries into one set of reports | Requires intercompany elimination, covered below |
| Multi-currency | Records and translates foreign currency | Needs stored rates, not on-the-fly recalculation |
| Audit trail | Immutable, attributed history | The first thing an auditor asks to see |
| Permissions and approvals | Roles, posting limits, segregation of duties | Finance teams need segregation, not just an admin flag |
This is the part that turns a simple ledger into a real project, and it is where most build-versus-buy decisions get made.
A group of companies is, for reporting purposes, one economic entity. When subsidiary A sells goods to subsidiary B, that sale is revenue in A's books and a cost in B's, but from the outside it is neither. If you simply add the two entities' numbers together, you inflate revenue and profit with transactions that never left the group. Consolidation exists to strip those out.
Both major frameworks require it. IFRS 10 and US GAAP's ASC 810 both state that intra-group balances and transactions must be eliminated in full before consolidated statements are presented. The mechanics are the same regardless of framework: aggregate the entities line by line, eliminate the intercompany balances and transactions, then present the group as a single entity, with any noncontrolling interest shown separately.
In software terms, elimination forces a data-model decision you have to make on day one. Every entry has to carry two pieces of information: which entity it belongs to, and which counterparty entity it involves. A sale from A to B is tagged as A's revenue with B as the counterparty. Without that counterparty tag, you have no way to find and cancel the intercompany pairs, and consolidation becomes a manual spreadsheet exercise again. Retro-fitting this tag onto a ledger that was built single-entity is one of the more expensive mistakes we see, because the entries already stored lack the field the whole feature depends on.
Intercompany elimination covers more than sales. Loans between entities, dividends paid up the chain, management fees, and unrealized profit on inventory that one entity sold to another all have to come out. Multi-currency makes it a layer deeper: each subsidiary may keep books in its own functional currency, so you translate each entity first, then consolidate, then present in the group currency. We covered the currency side in detail in our guide on building a multi-currency accounting platform.
The accounting logic is where custom builds either earn their cost or waste it, and none of it shows up in a demo. A few rules matter more than the rest.
Money is never stored in floating point. IEEE 754 doubles turn 0.10 plus 0.20 into 0.30000000000000004, and across a few hundred thousand transactions the books stop tying out. Store amounts as integers in minor units, or as a decimal type end to end. This is a decision made in the first week and it is expensive to reverse.
Posted entries are immutable. When someone makes a mistake, the correction is a reversing entry, not an overwrite. That keeps the audit trail complete and makes the system defensible to an auditor.
Balance is enforced in the database. The ledger should refuse an unbalanced entry regardless of what the interface tries to do. If the UI is the only place that checks, a bulk import or an API call will eventually write bad data.
Period-end jobs are idempotent. Revaluation, translation and the close itself must produce the same result when run twice. If running a job twice doubles its effect, you have a bug that will only surface at the worst possible moment, which is the close.
These four things decide whether the first month-end ties out or becomes an all-hands investigation. A team that has built financial systems before knows to treat them as requirements, not refinements. We wrote more about that mindset in our piece on financial management system development.
A general ledger lands in one of three bands, and the band is set by how much accounting correctness you need, not how many screens you have.
| Scope | What it includes | Typical range | Timeline |
|---|---|---|---|
| Single-entity ledger module | Chart of accounts, double-entry engine, journals, trial balance, one set of statements | $40,000–$90,000 | 2–4 months |
| Full accounting engine | Adds AP/AR sub-ledgers, multi-currency, reporting, close workflow | $90,000–$200,000 | 4–8 months |
| Multi-entity consolidation | Adds intercompany elimination, multi-currency translation, consolidated statements | $200,000–$400,000+ | 6–12 months |
These are ranges, not quotes. The number that matters is the one in a scoped proposal, and two honest vendors can be 2x apart on the same project for reasons that have nothing to do with incompetence. I explain how to read those quotes in why custom software quotes vary.
The pattern to notice is that the expensive part is not the interface. A basic ledger has a simple data model and a few screens. The cost climbs with consolidation, multi-currency, and the integrations and controls around the close, because that is where the accounting logic lives and where the risk sits.
Six things push a ledger build from the basic band to the enterprise band.
The number of entities and intercompany relationships. Every new entity is a new set of books and a new set of elimination pairs. Twelve entities are not six times the work of two; the combinations grow faster than the entity count.
Multi-currency. Translation, revaluation, and the split between realized and unrealized gain or loss all add real scope, and they add testing burden because the edge cases only appear at period boundaries.
Regulatory and compliance requirements. The jurisdiction the company reports in decides how much control and audit work has to be built in. A finance team preparing for an audit needs segregation of duties, approval chains and a complete, immutable trail, and that is its own work stream.
Integrations. A bank feed and a payment processor are the minimum. Tax calculation, payroll, an ERP, or a legacy system add mapping, error handling and testing, and each one is a place where the schedule quietly slips.
Data migration. Moving off an existing ledger means mapping and cleaning years of history, and it always takes longer than the estimate. Price it as its own line, not as part of the build.
Reporting depth. Consolidated statements, dimensional reporting by segment or department, and custom report definitions all add cost on top of the core ledger. The ledger is the foundation; the reporting is where finance teams ask for the most.
For a business that just needs correct books, buying is usually the right call. Established accounting products handle single-entity and even basic multi-entity books well, and integrating one is far cheaper than a build. We walked through that trade-off in accounting software: build, buy, or extend.
A build makes sense in three situations. The ledger is part of a product you sell, so off-the-shelf is not an option. Your consolidation and reporting rules are specific enough that no tool fits. Or you have outgrown the tool you are on, and the cost of working around it every month exceeds the cost of replacing it.
The test I use is simple: is the ledger your product, or a chore inside your product? If it is a chore, buy. If it is the product, build, and treat the accounting correctness as the thing you are actually paying for.
Start single-entity and single-currency even if you plan to end up multi-entity. The important thing in version one is the entry model and the double-entry engine, and those are easier to get right before the consolidation logic sits on top. Design the data model with the entity and counterparty tags from day one, even if you do not use them yet, because adding them later means rebuilding the ledger.
Fix the chart of accounts before writing code. A chart that gets renamed six months in is a data migration event, not a config change.
Cap the integrations in phase one. A bank feed and one payment processor get you to a working close. Defer the rest.
Ship the close workflow early. It is the fastest way to expose the data-model problems, and it is what your finance team will actually judge the system by.
If you are still deciding how much to build before launch, our guide on defining an MVP before hiring developers applies to ledgers as much as to any other product.
A single-entity ledger module runs $40,000 to $90,000. A full accounting engine with sub-ledgers and multi-currency runs $90,000 to $200,000. Multi-entity consolidation with intercompany elimination runs $200,000 to $400,000 or more. These are ranges, not quotes.
The general ledger holds the master accounts and the summarized balances. A sub-ledger, such as accounts payable or accounts receivable, holds the detail behind those balances and posts totals to the GL's control accounts. The two must reconcile.
Only if you have multiple legal entities that report as a group today. But design the data model with entity and counterparty tags from the start even if you are single-entity, because adding them later means rebuilding the ledger.
That depends on your reporting jurisdiction, not on the software. IFRS 10 and ASC 810 govern consolidation. IAS 21 and ASC 830 govern foreign currency. The software's job is to store enough information that you can comply with either, which comes down to the data model rather than hard-coded rules.
Two to four months for a single-entity module, four to eight months for a full accounting engine, and six to twelve months for multi-entity consolidation. Consolidation and integrations stretch the calendar more than the core ledger does.
Buy if the ledger is a chore inside your product. Build if the ledger is the product, or if your consolidation and reporting rules are specific enough that no off-the-shelf tool fits.
GlobeSoft is a software development company founded in 2018, with 40-plus engineers and more than 300 delivered projects for over 100 clients across the US, Brazil, South Africa and Singapore. We build custom software, mobile apps, SaaS platforms, FinTech systems, ERP and CRM, and AI products on a stack that includes Java, Spring Boot, Spring Cloud, Go, Python, React, Vue, Node, MySQL and Redis. We run overlapping hours with our clients, keep a dedicated group per project, and communicate in English and Portuguese.
A general ledger is the kind of project where the first 90 percent is straightforward and the last 10 percent is careful, correctness-driven work. If you are planning one, talk to us about your project. Tell us how many entities you have, what currencies they run in, and what your close looks like today, and we will help you work through build-versus-buy, the ledger data model, and a realistic scope before you write a line of code.
Tell us what you are building and where you are today. We typically reply within 24 hours.
