Financial services accounting software gets bought for a reason that rarely reaches the requirements document: your month-end runs twice. Once in the accounting system, and again in a workbook where entities get stacked, intercompany balances are knocked out by hand, and last month’s rates are pasted into a tab nobody wants to own.
That second close is where the risk sits. It is unversioned, it depends on one person, and it is the version investors and the board actually read. When an auditor asks how a consolidated figure was produced, the honest answer involves a filename.
Removing it is mostly not a software problem. Any serious platform will consolidate. Whether it consolidates correctly on the first close after go-live depends on four decisions taken in the first month: entity structure, currency treatment, dimensions, and who may post what. Here is what those decisions look like from the implementation side. For the wider platform view, our page on Sage Intacct finance software solutions covers the ground above this one.
Key Takeaways
- Entity structure is the decision you cannot cheaply reverse. Consolidation, elimination and investor reporting all inherit from it, and re-parenting entities later means restating history.
- Multi-currency is two problems, not one. Holding a transaction in the currency it was struck in is the first; translating balances for reporting is the second. Firms that solve only the second find out at audit.
- Your dimension design decides what investor, board and regulatory reporting can slice by. If fund, strategy, vehicle or adviser is not captured at entry, no report will produce it afterwards.
- Audit readiness is a configuration outcome, not a feature: approval workflows matching your real delegation of authority, separated duties, and an unbroken path from a consolidated figure back to its source document.
- The ledger rarely replaces fund administration. Decide early which entities it runs and which stay in a specialist system, then design the join deliberately.
Screenshots throughout are Sage Intacct product material. The figures shown in them are Sage’s demonstration data, not Lucentive client results.
What financial services accounting software has to handle that a generic ledger does not
Three things, roughly in order of how much trouble they cause. Many legal entities that consolidate and eliminate against one another. More than one currency, held at both transaction and reporting level. And obligations to people outside the company, who each want the same numbers cut differently and on their own deadline.
The label covers firms that look nothing alike commercially. A registered investment adviser, a private credit manager, a multi-family office and an insurance brokerage sell very different things. Their ledgers share a shape: a management company carrying most of the cost, vehicles or funds carrying the revenue, and a reporting cycle driven by somebody else’s calendar.
That shape is why generic accounting works until it abruptly does not. A single-entity ledger handles the management company fine. It fails at the third entity, at the first non-functional currency, and the first time an investor asks for a figure the chart of accounts cannot isolate.
Multi-entity consolidations without the second workbook
Consolidation stops being a monthly project when entities share one chart of accounts, one vendor and customer master and one fiscal calendar, and when intercompany eliminations run as configured rules rather than journals somebody remembers to post. Reaching that point is structural work, not reporting work.
The work starts with a hierarchy: which legal entities exist, which roll into which, and which are consolidated rather than equity-accounted. Firms regularly discover here that their legal structure and their management reporting structure have quietly diverged. Both views are legitimate. They need to be two reporting hierarchies over one ledger, not two sets of books.
The dashboard above is roughly where controllers land: headline measures across the top, revenue split by entity, aging and payables underneath. The detail worth noticing is the eliminations slice in the revenue breakdown. In a working configuration that slice is produced on demand, not by a journal raised on the fourth working day.
Two practical points decide whether the first consolidated close is calm. If each entity keeps its own vendor and customer list, intercompany matching stays manual, so that cleanup belongs before conversion. And minority interests need their treatment agreed with your auditor during design, because retrofitting a non-controlling interest presentation is painful. Our note on consolidating and automating finances for multi-entity organisations sets out the operating case behind this.
[DATA: Lucentive’s actual reduction in consolidated close time across multi-entity financial services clients — Rich to confirm]
Multi-currency: the part that gets underestimated
Currency is two mechanisms and most evaluations test only one. Transactional currency records a payable in the currency it was struck in and revalues it as rates move. Reporting currency translates balances for consolidation. A demonstration showing a translated income statement proves the second and says nothing about the first.
The questions worth asking are unglamorous. Where do rates come from, and who approves them? Can different rate types apply to different classes of account? Where do realised and unrealised gains and losses land, and will your auditor accept those accounts without a supporting schedule?
Firms with offshore vehicles get caught in a particular way. The vehicle is denominated in one currency, the manager reports in another, and some investors sit in a third. That is three translations, and the point at which each is applied changes the answer. Agree the treatment with your auditor and administrator during design and configure to the written version. Settling it during the first live close is how a manual override ends up outliving everyone who understood it.
Financial services multi-dimensional reporting and real-time visibility
Dimensions are tags carried by every transaction: entity, location, department, fund, strategy, vehicle, adviser, or whatever your business is genuinely organised around. They are how the ledger answers the question “by what?”. Real-time visibility is downstream of them, because a dashboard can only group and total by something the ledger already knows.
The explorer view above is the analyst’s tool rather than the controller’s: revenue trended by quarter, margin plotted by location, expense mix broken out per site. It reads the same live ledger the statutory reports read, and that shared source is what matters. When the board deck and the audited accounts come from one place, the reconciliation meeting stops appearing.
Investors, boards and regulators want different cuts, and one design has to serve all three. Investors want figures by vehicle and strategy, on their own calendar. The board wants trend and budget variance. Regulators want a defined schedule at a defined grain, and here expectations need managing honestly: the ledger does not file your returns, it supplies the numbers those returns consume. Settle during design whether it can supply them at the grain the filing demands without a manual re-cut. If it cannot, the workbook you were deleting returns under a new name.
The dimension work is the whole game, and our sibling piece on how Sage Intacct dimensions work is worth reading before the design workshop. Two rules save the most rework. Capture dimensions at entry rather than reconstructing them at reporting time, and keep the count small enough that the people entering transactions apply them correctly every time. A dimension applied inconsistently is worse than one that does not exist: it produces reports that look complete.
Audit readiness: manage costs, assign controls, keep the trail intact
Audit readiness is not a module you switch on. It is what you get when three things are configured deliberately: approval workflows matching your real delegation of authority, permissions separating whoever raises a transaction from whoever releases it, and an unbroken path from any consolidated figure back to the document behind it.
Cost allocation deserves its own conversation: in a manager structure it is where most audit friction lives. Shared costs — premises, technology, compliance, staff working across the manager and the vehicles — have to be assigned on a basis that is consistent, documented and repeatable. Allocation rules configured in the ledger are defensible in a way a spreadsheet is not: they run the same way every period and they show their working.
Internal controls are mostly a design exercise about people rather than software. Who approves an invoice, and above what threshold does it need a second approver? Who can post to a closed period? Who can create a vendor, and is that the person who can pay one? Answer those before configuration and the system enforces your policy; answer them afterwards and you have configured somebody’s habits. Our approach to data quality assurance is worth reading before the first load.
On the platform itself, ask Sage for the current SOC report rather than assuming one exists at the level your auditor expects. Our piece on security in Sage Intacct covers that side.
What fund and asset-manager structures demand from a ledger
A management company, one or more general partner entities, the funds themselves, and often holding vehicles beneath them. Each is a separate legal entity with its own accounts, auditor and investors, and the flows between them — management fees, expense recharges, capital calls, distributions — are the part that defeats generic systems.
The most important scoping decision is the boundary between the accounting ledger and fund administration. In most structures we work on, the ledger runs the management company, the general partner entities and the operating side, while partnership accounting, investor capital accounts, waterfall calculations and net asset value stay with a specialist platform or the administrator. That division is normal rather than a shortcoming. What matters is deciding it explicitly and designing the interface, not finding the gap during user acceptance testing.
Management fees and expense recharges then need modelling as real transactions between real entities, so they eliminate on consolidation and reconcile to what the funds were charged. Carried interest usually sits outside the ledger and arrives as a journal; agree who produces it and on what schedule before go-live. Family offices face a near-identical problem with a different audience, and our sibling page on family office accounting software works through it.
[DATA: the largest multi-entity structure Lucentive has implemented, by number of legal entities — Rich to confirm]
What the endorsements, badges and datasheets actually tell you
Less than the marketing implies, and more than nothing. Sage markets Sage Intacct as the AICPA’s preferred provider of financial applications, a designation made through CPA.com. Peer-review badges say buyers rated the product well. Both are genuine signals about the product. Neither says anything about whether your implementation works.
The page this one replaces ended in three gates: a datasheet, a report and an eBook, each behind a form. Those documents describe capability, the easy half of the decision and broadly comparable across serious platforms. A datasheet cannot tell you whether your entity hierarchy, currency treatment and dimension design will be built correctly, and that is the half that decides the outcome.
Where these implementations stall is consistent enough to list. Entity structure agreed after configuration has started. Master data cleanup treated as a data task instead of a design task. Nobody named internally to own the chart of accounts and dimensions once the consultants leave. The fund-administration boundary left undefined until testing. All four are decisions, not defects, and all four are cheap early.
Summary
The gap between a firm that closes once and a firm that closes twice is almost never the software. It is four early decisions: the entity hierarchy, the currency treatment, the dimension design, and the line between ledger and fund administration. Get those right and consolidation, investor reporting and audit readiness become consequences, not projects.
If you are evaluating now, the most useful preparation costs an afternoon. Draw your legal entity structure, mark every currency that appears anywhere in it, and list every report you send outside the company with its deadline. Bring that to a conversation and our consultants will tell you which parts are straightforward configuration, which need a process change first, and which belong in fund administration rather than a ledger. Start a conversation with our team once you have it.
Frequently Asked Questions
Is accounting part of financial services?
In most industry classifications they sit side by side rather than one inside the other. Financial services covers investment management, banking, lending, insurance and advice; accounting is a professional service those firms consume. The terms blur in software conversations because a financial services firm needs a ledger built for the structures it operates, while a general package assumes one trading company.
What is the difference between financial services and accounting for software purposes?
Accounting software records what your own business does. Financial services accounting software does that while also handling entities that consolidate and eliminate against each other, more than one currency, and reporting to outside parties on their calendar. Feature lists look similar. The difference shows up in the second month, when the consolidated close either runs or turns back into a workbook.
What is the difference between Sage and Sage Intacct?
Sage is the company, and it publishes several accounting products at different sizes, including desktop and mid-market lines. Sage Intacct is its cloud financial management product, aimed at organisations that have outgrown single-entity accounting. They are separate products rather than tiers of one, so moving between them is an implementation with data migration and redesign, not an upgrade you click through.
Can it handle multi-currency consolidation for offshore vehicles?
Yes, and the answer depends far more on configuration than capability. You need transactional currency on the entities that trade in it, a defined rate source with a named approver, an agreed treatment for realised and unrealised movement, and a reporting currency at each level of the hierarchy. Agree all four during design, because changing the treatment later affects every comparative report.
Does it replace our fund administration system?
Usually not, and be sceptical of anyone who says it does. Partnership accounting, investor capital accounts, waterfall calculations and net asset value are what fund administration platforms exist to do. The ledger runs the management company, the general partner entities and the operating side, joined to it by a defined interface. Deciding that boundary at scoping is one of the highest-value hours in the project.
How long does a multi-entity implementation take?
It depends far less on the number of entities than on how settled your structure and master data are. A firm with a clean hierarchy, one currency and tidy vendor records moves quickly. A firm still arguing about which entity owns which cost, with duplicate vendors across five ledgers, spends most of the project on design and cleanup.
[DATA: Lucentive’s typical implementation timeline for a multi-entity, multi-currency financial services firm — Rich to confirm]