General ledger in healthcare explained

The general ledger in healthcare does more than record transactions — it is the structural foundation that determines whether a finance team can produce accurate financial statements, survive an audit, or generate the cost-per-encounter analysis that operational decisions depend on. Most off-the-shelf accounting platforms are not built for what healthcare actually requires: simultaneous tracking of gross charges and contractual adjustments across multiple payers, cost center coding granular enough for provider-level profitability analysis, and a consolidation architecture that can handle management fees, intercompany eliminations, and entity-level books within the same health system.

The gap between a generic GL and a healthcare-grade one is not a configuration problem. It is an architectural one — and it compounds with every new entity, payer contract, or grant added to the organization.

This article covers the five structural dimensions of a healthcare GL, how revenue recognition works in practice, where multi-entity organizations break down, the most consequential GL mistakes finance teams make, and what to look for in a platform built to handle it.

Key takeaways

• A healthcare GL requires at least five dimensions of account coding — entity, department/cost center, provider, payer/program, and project/grant — to support the reporting that audits, payer analysis, and cost-per-encounter calculations actually require.
• Gross charges and net patient revenue are not interchangeable figures: a $500 charge reduced by a $200 contractual adjustment and a $50 charity care write-off yields $250 in net patient revenue, and conflating the two in reporting inflates apparent revenue and distorts margin analysis.
• Contractual adjustments are pre-negotiated, expected reductions — not bad debt — and must be recorded as contra-revenue accounts broken out by payer; without that granularity, finance teams cannot identify which payer contracts are underperforming.
• Multi-entity healthcare organizations — health systems, DSOs, MSOs — must record management fees as intercompany transactions in both the charging and receiving entity's GL, then eliminate both entries at consolidation; recording the fee in only one entity is one of the most common causes of inflated group-level revenue.
• Nonprofit healthcare organizations must layer fund accounting onto the standard GL structure to segregate restricted and unrestricted net assets under ASC 958, effectively adding a sixth dimension to the account coding structure.
• Period locking, consistent chart of accounts mapping across entities, and cost center coding discipline are operational controls that determine whether a healthcare GL can support an external audit or consolidated reporting — they are not optional configuration choices.

What is a general ledger in healthcare?

A healthcare general ledger is the central accounting record that captures every financial transaction across a healthcare organization — revenue, expenses, assets, liabilities, and equity — and serves as the authoritative source for financial reporting, compliance, and cost analysis.

Every downstream output a healthcare finance team produces depends on what lives in the GL and how it is structured. Consolidated financial statements, audit trails, cost-per-encounter analysis, payer profitability reports, Medicare cost reports — all of them trace back to the quality and granularity of GL entries. A poorly designed GL does not just create reporting inconvenience; it produces materially unreliable numbers that cannot support audit scrutiny or operational decision-making.

What distinguishes the general ledger in healthcare from a standard commercial GL is not the fundamental accounting mechanics — debits and credits still balance — but the layers of classification that healthcare transactions require. A single patient encounter can generate revenue attributable to a specific payer, billed under a specific provider, within a specific department, at a specific entity, and potentially tied to a restricted grant or program. Each of those dimensions needs to be captured in the GL at the time of posting, not reconstructed later from a practice management system export.

Why healthcare GLs are more complex than standard commercial ledgers

A commercial business typically needs to track revenue by product line and expenses by department. A healthcare organization must do considerably more. Revenue arrives through multiple streams — fee-for-service, capitation, grants, 340B drug program savings — each with different recognition rules under ASC 606 or ASC 958. A hospital system billing Medicare, Medicaid, and two commercial payers simultaneously needs separate contractual adjustment accounts for each payer, because the discount from gross charges to net patient revenue differs materially by contract.

Cost center segmentation adds another layer. Regulatory reporting requirements — including Medicare cost report preparation — mandate that expenses be tracked by clinical department, not just by natural account. Without that segmentation built into the GL, finance teams are forced to allocate costs after the fact, introducing estimation error into reports that regulators and auditors will scrutinize.

Multi-entity structures compound the complexity further. A health system that includes a hospital, a physician group, a management services organization, and a nonprofit foundation cannot manage all of those entities in a single-company general-purpose accounting platform without significant architectural workarounds. Each entity may have distinct revenue recognition rules, reporting obligations, and — in the case of the nonprofit — fund accounting requirements. For organizations navigating this kind of structure, understanding the financial consolidation process at the group level is as important as getting the entity-level GL right.

How a healthcare general ledger is structured

A healthcare GL is organized around five distinct coding dimensions — entity, department/cost center, provider, payer/program, and project/grant — and this multi-dimensional structure is what separates a healthcare-grade ledger from a generic commercial one. Call this framework The Five Healthcare GL Dimensions. Each dimension exists because it enables a specific category of reporting that healthcare finance teams cannot operate without: entity for consolidation, cost center for operational cost analysis, provider for productivity and compensation, payer for contract performance, and project/grant for restricted fund compliance.

A standard commercial GL might track transactions by account and department. A healthcare GL must track them across all five dimensions simultaneously — because a single physician encounter can generate revenue that is attributable to a specific entity, billed under a specific payer contract, assigned to a specific provider, coded to a specific cost center, and funded in part by a restricted grant. Collapsing any one of those dimensions into a catch-all account destroys the analytical value of the ledger.

The five healthcare GL dimensions

1. Entity — identifies the legal entity in which the transaction originates, enabling entity-level financial statements and, for multi-entity organizations, a consolidation layer that rolls up individual books into group financials. For a health system with hospital, physician group, and MSO subsidiaries, every transaction must carry an entity code before consolidation is possible. (For a deeper look at how entity-level books feed into group reporting, see this overview of group consolidation fundamentals.)
2. Department/cost center — assigns each transaction to a specific operational unit, such as the emergency department, primary care clinic, or radiology suite. This is what makes department-level cost analysis possible and what drives Medicare cost report preparation.
3. Provider — tracks revenue and cost by individual clinician, enabling RVU-based compensation reconciliation, provider-level profitability analysis, and productivity benchmarking against compensation thresholds.
4. Payer/program — segments transactions by the payer responsible for reimbursement: Medicare, Medicaid, a specific commercial insurer, or a capitation arrangement. Without this dimension, finance teams cannot identify which payer contracts are generating positive margin and which are not.
5. Project/grant — tags transactions to a specific funded project or grant award, which is essential for restricted fund compliance, grant drawdown reporting, and 340B program tracking.

Healthcare chart of accounts: revenue and expense structure

The chart of accounts in a healthcare GL must carry significantly more account-level granularity than most industries require. On the revenue side, a well-structured COA separates gross charges by service line, maintains dedicated contractual adjustment accounts by payer, and isolates net patient revenue as a distinct line item. Other operating revenue — cafeteria, parking, grant income — belongs in separate accounts, not pooled into a single "other revenue" bucket.

A practical example illustrates why payer-level granularity matters: a primary care group with Medicare, Medicaid, and two commercial contracts needs at minimum five contractual adjustment accounts to report net revenue accurately — one for each payer's pre-negotiated reduction from gross charges. Without that separation, the income statement shows gross charges rather than what the organization actually collects, and payer-level margin analysis becomes impossible.

On the expense side, the COA should distinguish clinical labor (physicians, nurses, allied health professionals) from non-clinical labor (administration, billing, IT), and further separate medical supplies, occupancy, depreciation, and purchased services. Grouping all labor into a single account is a common shortcut that eliminates any ability to analyze clinical vs. administrative cost ratios — a metric that matters significantly in value-based care contracting.

Fund accounting for nonprofit healthcare organizations

Nonprofit healthcare organizations — including hospitals, Federally Qualified Health Centers (FQHCs), and community health centers — must layer fund accounting onto the standard GL structure to comply with ASC 958 and satisfy funder reporting requirements. This effectively adds a sixth dimension to the GL for these organizations.

In practice, this means the GL must segregate restricted net assets — funds that carry donor or grantor conditions on their use — from unrestricted net assets, which the organization can deploy at its discretion. A federal grant restricted to maternal health services cannot be commingled with general operating revenue; it must be tracked in dedicated GL accounts and reported against the grant agreement's allowable cost categories. Misclassifying restricted funds as unrestricted — or failing to track them at the account level — is a finding that surfaces in both external audits and federal program reviews. For nonprofits evaluating whether their current GL architecture supports this level of segregation, the question is whether the platform supports dimensional fund coding natively or requires a workaround.

Revenue recognition in the healthcare general ledger

Revenue recognition is the single most complex area of healthcare GL management — and the most consequential when it goes wrong. The core problem is straightforward to state but difficult to execute: what a healthcare organization charges and what it actually collects are dramatically different numbers, and the GL must capture both figures — along with every adjustment in between — to produce financial statements that are accurate and auditable. ASC 606 governs revenue recognition across industries, but in healthcare its application is shaped by payer contracts, charity care policies, and program-specific restrictions that most other industries simply do not encounter.

Gross charges vs. net patient revenue

Gross charges are the full list price billed for a service before any payer-negotiated reductions, charity care adjustments, or bad debt write-offs are applied. Net patient revenue is what remains after all of those reductions — and it is the only figure that belongs on the income statement as recognized revenue.

Both numbers must live in the GL. Gross charges provide the starting point for payer contract analysis and rate negotiation; net patient revenue is what finance teams report externally. A concrete example makes the gap clear: a $500 charge reduced by a $200 Medicare contractual adjustment and a $50 charity care write-off yields $250 in net patient revenue. Reporting $500 as revenue overstates the top line by 100% — a material misstatement that distorts every downstream margin calculation.

Contractual adjustments: how payer contracts reduce gross charges

Contractual adjustments are the pre-negotiated reductions between a provider and a payer — not bad debt, not billing errors, but expected and formulaic reductions that are known at the time of service. In the GL, they are recorded as contra-revenue accounts: a debit to a contractual adjustment account that reduces gross charges to the expected collection amount.

A well-structured healthcare GL maintains separate contractual adjustment accounts by payer. A primary care group billing Medicare, Medicaid, and two commercial payers needs at minimum four distinct contractual adjustment accounts — one per payer — to enable meaningful payer-level profitability analysis. Without that granularity, finance cannot identify which contracts are generating acceptable margins and which are eroding them.

Charity care and bad debt in the GL

Charity care and bad debt are frequently confused, but their accounting treatment is entirely different. Charity care refers to services provided at no charge to qualifying patients under the organization's financial assistance policy; under ASC 606, these amounts are never recognized as revenue in the first place. They reduce gross charges before any revenue recognition occurs and are disclosed in the notes to the financial statements — they do not appear as either revenue or expense on the income statement.

Bad debt, by contrast, is revenue that was recognized and billed but later deemed uncollectible. Depending on the organization's accounting policy, bad debt is recorded as either a contra-revenue account or an operating expense. Misclassifying charity care as bad debt — treating it as a write-off after the fact rather than a pre-recognition exclusion — is one of the most common audit findings in healthcare, and it inflates both gross revenue and expense simultaneously.

340B and grant revenue: tracking restricted revenue in the GL

340B drug program savings and grant revenue require dedicated GL treatment that a generic "other revenue" account cannot support. For 340B, the savings generated through discounted drug acquisition must be tracked by eligible patient encounter and program type to satisfy HRSA audit requirements — a single pooled account provides no defensible audit trail. For grant revenue, recognition timing and conditions are governed by the grant agreement itself: nonprofit healthcare organizations follow ASC 958, which requires distinguishing between conditional and unconditional contributions, while for-profit entities apply ASC 606.

The practical implication is that any healthcare organization participating in 340B or receiving federal or state grants needs dedicated GL accounts and project or grant dimension codes assigned at the transaction level. This is precisely the kind of restricted revenue tracking that benefits from a consolidated income statement structure that can report restricted and unrestricted activity separately — a requirement that becomes even more pressing when multiple entities within a health system participate in the same programs under different eligibility criteria.

The multi-entity GL challenge in healthcare

Multi-location and multi-entity healthcare organizations — health systems, dental service organizations (DSOs), management services organizations (MSOs), and multi-specialty physician groups — face GL complexity that single-entity accounting software simply cannot handle. The core problems are structural: inconsistent charts of accounts across entities, untracked intercompany transactions, and no systematic consolidation layer. Finance leaders who recognize these patterns in their current setup are usually looking at an architectural problem, not a process one.

Common multi-entity GL problems in healthcare organizations

Most multi-entity healthcare finance teams encounter the same four structural failures, regardless of organization type or size:

• Inconsistent charts of accounts across entities. When a health system acquires a new practice or clinic and onboards it with a different account numbering convention, consolidation immediately becomes a manual reconciliation exercise. One entity codes physician compensation to account 6100; another uses account 6200. Without a unified chart of accounts or a reliable mapping layer, consolidated labor expense is unreliable every single period.
• Untracked management fees. Fees charged by an MSO or parent entity to clinical subsidiaries are frequently recorded inconsistently — sometimes as a reduction of expense in the receiving entity, sometimes as revenue in the charging entity, sometimes not recorded at all. Either way, the group-level income statement is wrong.
• Missing intercompany eliminations. Intercompany revenue and expense that is not eliminated at consolidation inflates group-level revenue and distorts margin. This is not only a reporting problem — auditors flag it, and lenders reviewing consolidated financials will identify it. The fix requires both a defined process for identifying intercompany transactions at period close and a system capable of tracking and eliminating them.
• No consolidation layer. Entity-level books exist, but there is no systematic process for rolling them up into consolidated financials. The result is a close process that lives in spreadsheets, takes significantly longer than it should, and introduces reconciliation errors that compound over time.

GL architecture options for multi-entity healthcare organizations

Two primary architectural approaches exist for multi-entity healthcare GL management, and the tradeoffs between them are meaningful.

The first approach is entity-level books with a separate consolidation layer — each entity maintains its own GL in a general-purpose accounting platform, and a consolidation tool aggregates trial balances, maps accounts, and eliminates intercompany transactions at reporting time. This approach is more flexible and lower-cost to implement, and it preserves existing entity-level workflows. The risk is consolidation quality: if the underlying charts of accounts are not mapped consistently, or if intercompany transactions are not identified systematically, the consolidated output is only as reliable as the manual process behind it. For teams evaluating this path, see our comparison of multi-entity consolidation software to understand where different platforms sit on the automation spectrum.

The second approach is a unified ERP with a native multi-entity GL — a single platform maintains all entity books with a shared chart of accounts, built-in intercompany transaction tracking, and automated consolidation. This approach is more controlled and produces a more reliable consolidated close, but it requires meaningful upfront configuration and carries higher platform cost. For healthcare organizations managing five or more entities with active intercompany activity — particularly MSO-to-clinic management fee arrangements — the investment in a unified architecture typically pays for itself in close time and audit readiness.

How management fees between clinical entities should be tracked in the GL

Management fees — charges from an MSO, parent entity, or shared services center to clinical subsidiaries — must be recorded as intercompany transactions in both entities' books. The charging entity records the fee as intercompany revenue; the receiving entity records it as management fee expense. At consolidation, both entries are eliminated so the group-level income statement reflects only external revenue and expense. For a deeper look at how intercompany eliminations work across entity types, understanding group consolidation provides a useful structural overview.

The most common failure mode is recording the fee in only one entity — typically as an expense in the subsidiary but not as revenue in the MSO — which leaves the consolidation out of balance and creates an audit finding. Using dedicated intercompany GL account codes (rather than standard revenue or expense accounts) is what makes systematic elimination possible. As a concrete example: an MSO charges $50,000 per month to a clinical subsidiary. The MSO books $50,000 to intercompany revenue (e.g., account 4900-IC); the subsidiary books $50,000 to management fee expense (e.g., account 6800-IC). Both entries are eliminated in the consolidation layer, and neither appears in the group-level income statement. Without that dedicated account coding, there is no reliable way to identify and eliminate the transaction at scale.

Common GL mistakes in healthcare finance

The most consequential GL errors in healthcare are not random — they are predictable structural failures that appear repeatedly across organizations that have outgrown their original accounting setup. Each one has a specific downstream consequence: misleading margin reports, failed audits, or a consolidation process that cannot close on time. Use the list below as a diagnostic checklist against your current GL setup.

1. Mixing gross charges with net revenue in reporting. Reporting gross charges as if they were net patient revenue produces materially overstated revenue figures. A healthcare organization with $10M in gross charges and $4M in contractual adjustments has $6M in net patient revenue — reporting $10M inflates apparent revenue by 67%. This error is most common in organizations that migrated from a practice management system to a general-purpose accounting platform without restructuring the revenue accounts to separate gross charges from contractual adjustments.
2. Not maintaining cost center discipline. Cost center discipline — consistently coding every transaction to the correct department, provider, or facility — is what makes service-line and provider-level profitability analysis possible. When staff route expenses to a default or catch-all cost center, the GL loses its analytical value entirely: finance cannot identify which service lines are contributing positive margin or where cost reduction efforts should be focused. This is primarily a process and training failure, not a software problem — even a well-configured GL breaks down when coding discipline is inconsistent.
3. Inconsistent account mapping across entities. When different entities within a health system use different account numbers or naming conventions for the same transaction type, consolidation becomes a manual mapping exercise that introduces error and delays the close. A concrete example: one entity codes physician compensation to account 6100, another to account 6200 — without a unified chart of accounts or a mapping table, consolidated labor expense is unreliable. This problem compounds as entities are acquired or added without chart of accounts standardization, which is why understanding the financial consolidation process before adding entities is essential, not optional.
4. Missing intercompany eliminations. Intercompany transactions — management fees, shared service charges, intercompany loans — that are not eliminated at consolidation inflate both group revenue and group expenses simultaneously, making the consolidated income statement misleading on both sides of the ledger. Auditors will flag missing eliminations, and lenders reviewing consolidated financials will identify the discrepancy. The fix requires both a process (identifying all intercompany transactions at period close) and a system capable of tracking and eliminating them systematically.
5. No period locking. Without period locking — a control that prevents retroactive journal entries to closed accounting periods — the GL audit trail is unreliable. Retroactive entries can alter prior-period financial statements, creating discrepancies between reported figures and audited figures. Period locking is a basic control that most accounting platforms support natively, but many healthcare organizations fail to enforce it operationally. For organizations subject to Medicare cost report preparation or external audit, an unlocked GL is a material control deficiency that reviewers will not overlook. Finance leaders evaluating whether their current platform supports adequate close controls should review what the essentials of financial close actually require at the system level.

What to do if your healthcare GL isn't built for scale

If your finance team is spending significant close time reconciling spreadsheets, manually mapping accounts across entities, or producing consolidated financials through a series of exports and pastes, the problem is architectural — not operational. Better Excel hygiene will not fix a GL that was never designed to handle the five dimensions that healthcare reporting requires.

Start with two diagnostic questions. First: does your current GL support dimensional coding across entity, cost center, provider, payer, and project — and is that coding applied consistently on every transaction? Second: can your platform produce consolidated financials across all entities without a manual reconciliation step? If the answer to either question is no, you are carrying structural risk that compounds with every new entity, contract, or audit cycle.

The decision that follows is not simply "which software should we buy." It is a choice between three distinct paths, each with different cost, risk, and timeline profiles:

1. Reconfigure the existing platform. If your current GL supports dimensional accounting but the configuration is incomplete — missing payer-level contractual adjustment accounts, no intercompany account codes, inconsistent cost center usage — a targeted reconfiguration project may close the gap without a full migration. This path works when the platform is capable but the setup is immature.
2. Add a consolidation layer. If entity-level books are stable but consolidated reporting is the primary gap, a dedicated consolidation tool that sits above your existing GLs can produce group-level financials without requiring a platform replacement. This is a faster, lower-cost path, but it does not address underlying GL structure problems at the entity level.
3. Evaluate a purpose-built multi-entity accounting platform. For healthcare organizations managing three or more entities with active intercompany transactions, payer-mix reporting requirements, and external audit obligations, a mid-market ERP with native multi-entity GL capabilities is typically the most durable solution. See the best multi-entity consolidation software for 2026 for a structured comparison of platforms evaluated on intercompany elimination depth, audit trail quality, and implementation complexity.

Whichever path you pursue, the most useful first step is a gap analysis of your current chart of accounts structure. Document where dimensional coding breaks down — which entities lack payer-level revenue accounts, which cost centers are being used as catch-all buckets, which intercompany transactions have no dedicated GL account codes. That gap analysis is the most decision-useful input you can bring to any platform evaluation or reconfiguration conversation. It turns a vague sense that "the GL isn't working" into a specific, scoped problem that can actually be solved.

Build the GL architecture before the complexity forces you to

A healthcare general ledger that cannot separate gross charges from net patient revenue by payer, track intercompany management fees across entities, or produce consolidated financials without a manual spreadsheet process is not a reporting inconvenience — it is a structural liability that compounds with every acquisition, payer contract, and grant added to the organization. The five-dimension framework covered in this article — entity, cost center, provider, payer, and project — is the architectural baseline, not an advanced configuration.

If your current GL cannot support those dimensions natively, you are absorbing that gap as manual reconciliation work and audit risk. The most productive next step is a gap analysis of your existing chart of accounts structure against that framework — that document becomes the foundation for any platform evaluation worth running.

Frequently asked questions

How is a healthcare general ledger different from a standard business general ledger?

A healthcare GL requires multi-dimensional account coding across at least five dimensions — entity, department/cost center, provider, payer, and project/grant — while a standard commercial GL typically operates with a simple natural account and cost center structure. Healthcare organizations must also maintain separate revenue accounts for gross charges and contractual adjustments by payer, which has no equivalent in most commercial industries. Nonprofit healthcare entities add a sixth layer: fund accounting to segregate restricted and unrestricted net assets under ASC 958. Without this structural depth, a healthcare GL cannot produce the payer-level profitability analysis, provider productivity reporting, or consolidated financials that auditors, lenders, and health system leadership require.

How do contractual adjustments and charity care get recorded in the GL?

Contractual adjustments are recorded as contra-revenue — a debit to a payer-specific contractual adjustment account that reduces gross charges down to the expected net collection amount — and should be maintained in separate accounts by payer (Medicare, Medicaid, each commercial contract) to enable contract-level performance analysis. Charity care is treated differently: under ASC 606, services provided to qualifying patients at no charge are never recognized as revenue in the first place, so no revenue entry is made and no expense is recorded — the disclosure appears only in the notes to the financial statements. The most common audit finding in this area is misclassifying charity care as bad debt expense, which overstates both gross revenue and operating expenses on the income statement. Bad debt, by contrast, represents amounts billed but deemed uncollectible after the fact and is recognized as an expense or contra-revenue depending on the organization's accounting policy.

What chart of accounts structure is typical for a multi-location medical group?

A well-structured multi-location medical group uses a segment-based account string that combines an entity code, a department or cost center code, and a natural account number — with optional provider and payer segments appended for dimensional reporting. On the revenue side, the COA should include gross charges by service line, separate contractual adjustment accounts for each payer, and net patient revenue; a single revenue account is not sufficient when payer mix drives margin. Expense accounts should cover clinical labor (physicians, nurses, allied health), non-clinical labor (administration, billing, IT), medical supplies, occupancy, and overhead allocations from any shared services or MSO structure. The specific numbering convention varies by organization, but the dimensional architecture — not the account numbers themselves — is what determines whether the GL can support consolidated reporting and cost analysis.

How do you track management fees between clinical entities in the general ledger?

Management fees must be recorded as intercompany transactions in both entities: the charging entity (typically an MSO or parent) books the fee as intercompany revenue, and the receiving clinical entity books it as management fee expense, each using dedicated intercompany GL account codes rather than standard revenue or expense accounts. Using dedicated intercompany codes is what makes automated elimination possible at consolidation — if the fee is recorded to a standard revenue account in one entity and a standard expense account in another, the consolidation layer cannot reliably identify and eliminate the offset. At the consolidated group level, both the intercompany revenue and the management fee expense are eliminated so that only external transactions flow through to the group income statement. The most common failure mode is recording the fee in only one entity, which inflates either group revenue or group expenses and will be flagged by auditors reviewing consolidated financials.

What's the right way to set up the GL for a DSO or multi-practice dental group?

A DSO or multi-practice dental group needs a single, standardized chart of accounts applied consistently across every practice entity, with each entity maintaining its own set of books and a consolidation layer — either native to the ERP or handled by a dedicated consolidation tool — producing group-level financials. The management fee structure between the DSO holding entity and the clinical professional corporations must be recorded as intercompany transactions in both entities and eliminated at consolidation; inconsistent treatment of these fees is the most common GL problem in DSO structures. Cost center coding should capture both practice location and provider to enable location-level and provider-level profitability analysis, which is essential for DSO operators managing acquisition performance and same-store growth metrics. For platform guidance on which accounting systems support this structure without heavy customization, the Consolidate.io comparison of healthcare accounting platforms covers the multi-entity GL requirements specific to dental groups and DSOs.

Which accounting platforms handle multi-entity healthcare GL requirements without heavy customization?

Most small-business accounting platforms — QuickBooks and Xero included — require significant workarounds or third-party consolidation tools to handle multi-entity healthcare GL requirements, because they lack native dimensional coding, intercompany tracking, and automated elimination capabilities. Mid-market ERPs including Sage Intacct, NetSuite, and Microsoft Dynamics 365 offer native multi-entity and dimensional GL structures that are meaningfully better suited to healthcare organizations managing three or more entities, payer-level revenue tracking, and period-end consolidation. The right platform depends on entity count, transaction volume, whether the organization requires native fund accounting for nonprofit compliance, and how much configuration investment is feasible. For a structured side-by-side evaluation of platforms against multi-entity healthcare GL requirements, the Consolidate.io guide to healthcare accounting software provides an honest assessment of capabilities and limitations across the major options.

‍