Groups rarely struggle to close an entity. They struggle to close the group — because the eliminations, the intercompany positions and the translation all happen in a workbook after every entity has finished. Accounting Seed supports multiple ledgers, multiple companies and multiple currencies on the Salesforce platform. Twopir Consulting designs the entity and consolidation architecture, configures it, and builds the logic where configuration ends. Consolidate in the ledger, not in a spreadsheet.
All four figures are from a single documented Accounting Seed engagement with a 150-employee US client — a single-entity build, not a group consolidation programme. Read the full case study.
Twopir Consulting has delivered Salesforce and finance systems for 500+ organizations across 12+ years — including groups running several entities and currencies on one ledger structure.
Systems We Build On
A group's financial problems are rarely entity-level problems. They are consolidation problems — the structure that would let the group close automatically was never designed, so it is reconstructed each period in a workbook that one person understands. Every gap below is part of that reconstruction.
Every entity exports a trial balance, someone maps and combines them, and the group result exists only in a file. The audit trail from a consolidated number back to a transaction runs through a spreadsheet.
One side books the recharge in a different period or at a different rate. The difference is written off to a suspense account each quarter because chasing it costs more than it is worth, until it does not.
Rates are pulled manually, applied at whichever rate someone chose, and translation differences are plugged. The same month restated twice produces two answers and nobody can explain either.
The entities were set up at different times by different people, so the mapping to a group chart is itself a maintained artefact. Adding an entity means extending a mapping table rather than adding an entity.
An acquisition or a new territory means re-deciding structural questions that should have been settled once. Growth is slowed by the finance system rather than supported by it.
The books are kept for the statutory filing and the management view is derived afterwards, or the reverse. Either way one of the two numbers is always a reconstruction, and leadership sees it late.
Accounting Seed is an accounting platform built natively on the Salesforce platform. It provides general ledger, accounts receivable, accounts payable, billing, project accounting and financial reporting, with support for multiple ledgers, multiple companies and multiple currencies, and consolidated reporting across them. Because it is native rather than integrated, each entity's financial records sit on the same platform as its customers and its trading activity. Accounting Seed's own multi-company and multi-currency documentation covers the product surface; this page covers the architecture we design on it.
The distinction that matters is between capability and structure. The product supports several entities and currencies; whether your group closes cleanly depends on how ledgers, the chart of accounts, intercompany pairs, rate tables and elimination entries are designed — and that design is what this engagement is. It is also worth saying plainly where the boundary sits: a group with complex statutory consolidation, minority interests across many jurisdictions or a dedicated consolidation obligation may still want a specialist consolidation tool above the ledger. We will tell you which situation you are in during discovery rather than after the build.
The platform's own capability. None of this is something Twopir built — it ships with the product.
The service. We design the group architecture, then implement, configure and extend the product to match it.
The operating change. This is what a group controller notices in the first two closes.
"We support multi-entity" hides the only question that matters to a group controller: which of these do you actually need, and who designs the structure? Twopir Consulting offers all four, and the boundary between configuration and custom development is stated below rather than discovered halfway through a project.
| Engagement | What it covers | Where the boundary sits |
|---|---|---|
| Implement | Standing up the group: ledger per entity, group chart of accounts, currency and rate table setup, period calendars, users and cross-entity permissions, opening balances per entity."Accounting Seed multi-entity implementation" | Ends when every entity can close its own period and the group can produce a consolidated position. Standard product setup — no custom code involved. |
| Configure | Shaping the group to its structure: intercompany account pairs, elimination rules, translation policy, consolidated report layouts, approval routing per entity, cross-entity dashboards."Accounting Seed consolidation configuration" | Declarative only — Flow, formula fields, page layouts, permission sets and native settings. If it can be built without Apex, it belongs here and stays upgrade-safe. |
| Build on | Custom development where the configuration surface runs out: automated intercompany matching, complex elimination logic, minority interest calculation, statutory report formats, corporate ERP interfaces."custom Accounting Seed development" | Starts the moment a requirement needs Apex, a Lightning Web Component or an API. Written against supported objects, bulk-safe and tested — never by modifying the managed package. |
| Rescue | Restructuring a group that grew organically: entity two and three exposing the decisions entity one skipped, charts that diverged, intercompany that never matched, consolidation nobody trusts."Accounting Seed consolidation not working" | Begins with an assessment across every entity, not a rebuild. Charts can usually be converged in place; where they cannot, the assessment says so with the arithmetic behind it. |
If a single entity is the immediate problem, start with the vertical page that matches it, or with Accounting Seed Implementation if the deployment is live and not working.
These are the modules that decide whether a group closes cleanly, described as the design decisions they are. Every one of them is cheap to settle at the start and expensive to change after two years of postings.
A ledger per legal entity with its own periods and its own functional currency, structured so a new entity is an addition rather than a redesign of the ones already live.
A single group chart of accounts with the local detail each jurisdiction needs carried in dimensions rather than in divergent codes — which is what removes the mapping table nobody wants to maintain.
Recharges, transfers and shared-service allocations booked as matched pairs so both sides exist from the moment the transaction does, and a mismatch is an exception rather than a quarterly discovery.
Eliminations run as defined entries against the consolidation rather than typed into a workbook, so a consolidated number can be traced back to the transactions behind it.
Rate tables, rate types and the policy for which rate applies to which balance, configured once and applied consistently — so restating the same month twice produces the same answer.
Entity calendars, group close deadlines and the locking sequence between them, so a late correction in one entity cannot silently reopen a period the group has already reported.
Who can see and post to which entity, modelled in the Salesforce sharing model, so a shared-services team works across entities without every user seeing the whole group.
The documented sequence for adding the next entity — chart, calendar, currency, intercompany pairs, permissions, opening balances — so an acquisition is a checklist rather than a project.
A group's finance stack is only as good as its weakest handoff, and in a multi-entity structure the weakest handoff is usually the one to whatever sits above the ledger. This is the surface we build around Accounting Seed for groups.
| Systems | Business purpose | What moves, and which way |
|---|---|---|
| Salesforce · Accounting Seed | Keep each entity's customers, trading activity and money on one record so operating companies do not need their own reconciliation between CRM and ledger. | No integration Native — same platform, same database. Accounts, contacts and opportunities are shared objects, not synchronised copies. Entity segregation is handled in the sharing model rather than by separate systems. |
| Entity ledgers within the group | Let each company keep its own books and calendar while still rolling into one consolidated position. | No integration One database, several ledgers. Consolidation reads across ledgers rather than importing from them, which is what removes the export-and-combine step entirely. |
| Intercompany trading | Ensure both sides of a recharge or transfer exist, in the same period, at the same rate. | Entity ↔ entity Matched transaction pairs created together with elimination flags. Consumed by group finance, who see unmatched items as exceptions rather than finding them in a reconciliation. |
| Local banking & payment providers | Reconcile each entity against its own local banking arrangements without forcing one provider across the group. | Bank → ledger Cleared transactions import per entity in that entity's currency. Consumed by the local controller, with the group position derived rather than re-keyed. |
| Payroll & local statutory systems | Get local payroll and tax postings into the right entity and the right dimensions in each jurisdiction. | Source → ledger Journals post per entity against the group chart and its local dimensions. Consumed by local finance. Built per group — the per-jurisdiction mapping is the work. |
| Corporate ERP · consolidation tool | Serve groups whose parent reports on a calendar and in a system that is not theirs to change. | Bi-directional Trial balances and consolidation entries move both ways on an agreed cut, with a period lock so a late correction cannot silently reopen a period the group has already reported. Consumed by group finance. |
Integration work beyond the ledger runs through our Salesforce integration practice; the Apex behind elimination and matching logic is covered in custom Accounting Seed development.
Group structures are almost always designed around the entities that exist on the day the project starts, which is why the third acquisition breaks them. We design for the shape of the group rather than for its current membership.
We map the legal and operating structure: entities, ownership, functional currencies, statutory obligations, intercompany trading, shared services, close calendars, and what the parent needs and when. Output is an architecture, not a task list. Typically 2–3 weeks.
One group chart of accounts with local flexibility in dimensions, ledger and calendar structure per entity, intercompany pairing convention, translation policy and elimination approach — agreed with group finance, and with the auditor where consolidation is audited. Typically 3–4 weeks.
Native configuration first — ledgers, rate tables, consolidated report layouts, cross-entity permissions, dashboards. Custom Apex and Lightning Web Components only where the requirement genuinely exceeds it, such as automated intercompany matching or minority interest. Typically 6–10 weeks.
One entity at a time: migrate, reconcile, run a full period in parallel, sign off, then start the next. A simultaneous group cutover concentrates every unknown into one weekend, which is why we do not run them that way. Typically 2–4 weeks per entity, overlapping.
We run the first consolidated close with group finance, fix what real intercompany volume exposes, then write the entity onboarding runbook so the next acquisition is a checklist your own team can execute.
Durations are typical ranges and depend far more on the number of jurisdictions than on the number of entities. A two-entity, one-currency group is a short programme; a five-country group with statutory filings in each is not, and we say which one you are in after Phase 01.
Both are published Twopir Consulting engagements delivered on Accounting Seed and Salesforce. Both are single-entity builds — that is what the documented Accounting Seed evidence currently covers — and both turn on the same discipline a group needs: structure designed before configuration, and automation replacing manual reconciliation. Every figure is scoped to the business it was measured at.
Twopir's specialized Salesforce customization enabled efficient integration of third-party systems and streamlined administration and billing, leading to seamless financial operations and enhanced productivity. Automated mass billing and matter management minimized errors across our entire legal workflow.
Financial operations restructured on Accounting Seed and Salesforce — 17 automation modules delivered.
Twopir provided Salesforce customisation and integration services to help us build a robust, compliant, and scalable legal operations platform — connecting case management, document processing, and financial systems into one unified workflow. The result was transformative for how we run case-to-cash operations.
Operations connected across sites and systems on Salesforce, AWS and QuickBooks.
Multi-entity programmes fail on decisions made in week two — one chart or several, where intercompany is booked, which rate applies to which balance. Those are architecture questions, and they are cheap now and expensive in two years.
Structures built around today's entity list break on the third acquisition. We design the shape of the group, then populate it — which is why entity onboarding ends up a checklist rather than a project.
Divergent charts per entity are the root cause of most consolidation pain. We put local requirements in dimensions rather than in codes, which removes the mapping table nobody wants to own.
One entity live and closing before the next begins. A simultaneous group cutover concentrates every unknown into a single weekend, and there is no version of that which is worth the time it saves.
For most mid-market groups the ledger is enough. For a group with complex statutory consolidation across many jurisdictions it may not be, and we say so in discovery rather than after the build.
When intercompany matching or minority interest exceeds native setup, the same team writes the Apex, against supported objects so the vendor's upgrade path stays intact.
Configuration is anything achievable declaratively — ledgers per entity, rate tables, intercompany account pairs, consolidated report layouts, cross-entity permissions, Flow automation, dashboards. Custom development starts when a requirement needs Apex, a Lightning Web Component or an API: automated intercompany matching at volume, complex elimination logic, minority interest calculation, statutory report formats, or a corporate ERP interface. We always exhaust the configuration surface first, because declarative work stays upgrade-safe and your team can maintain it without us.
Twopir Consulting is a Salesforce Partner and a HubSpot Partner, and we implement, configure and build on Accounting Seed for multi-entity groups. Accounting Seed licences are bought from Accounting Seed directly — the vendor does not publish public pricing and quotes per company. We deliver the implementation and the custom development around it; we are not reselling the product.
Yes. Accounting Seed supports multiple ledgers, multiple companies and multi-currency accounting with consolidated reporting across them, on one Salesforce org. What determines whether your group closes cleanly is not that capability but the structure built on it: whether there is one group chart of accounts or several, how intercompany pairs are created, which rate applies to which balance, and how period locking works between entity and group calendars. Those design decisions are the engagement, and they are the reason two groups on the same product can have very different close experiences.
When the consolidation itself is the complex part rather than the bookkeeping underneath it. Indicators include statutory consolidation obligations across many jurisdictions with differing local GAAP, significant minority interests, complex ownership changing during the year, or a parent that mandates a specific consolidation platform. For most mid-market groups — a handful of entities, one or two reporting frameworks — the ledger structure is genuinely enough and a separate tool adds a reconciliation rather than removing one. We assess which situation you are in during discovery, and it is a conclusion we have reached in both directions.
It can, and in most cases it should not. Divergent charts are the single most common root cause of painful consolidation, because the group then depends on a mapping table that has to be maintained forever and extended for every new entity. The better pattern is one group chart with local requirements carried in dimensions — entity, jurisdiction, cost centre — which gives each local team the detail it needs for its own reporting while the group reads one structure. Where a jurisdiction genuinely mandates a prescribed chart, we handle that as a reporting mapping rather than as a separate ledger structure.
It depends far more on the number of jurisdictions than on the number of entities. A two-entity, single-currency group typically runs three to four months. A five-country group with statutory filings in each is a longer programme, and we roll it out entity by entity — one live and closing before the next starts — rather than cutting the whole group over at once. We confirm the schedule after the group discovery phase, because the variable is the local requirements we cannot see before it.
With an assessment across every entity rather than a rebuild of any of them. Groups that grew organically usually have one entity that was set up carefully and several that were configured to get live, and the divergence is in the chart of accounts and the intercompany convention rather than in the product. Charts can usually be converged in place with a mapping and a restatement of comparatives; intercompany conventions can be standardised going forward without unwinding history. Where a rebuild of one entity genuinely is cheaper, the assessment shows the arithmetic rather than asserting it.
Whether you are standing up a second entity, restructuring a group that grew by acquisition, or trying to shorten a group close — the first conversation is about your entity structure and your intercompany conventions, not about software.
Multi-entity, multi-currency & consolidation on Salesforce
