Dissecting the multi-entity reporting problem

Finance teams at scaling companies have to put up with all sorts of growth-related pains. But one of the most difficult and headache-inducing aspects of this particular flavour of finance is dealing with the complexity that comes with scaling across multiple entities.

In this article we’ll explore the challenges with multi-entity reporting. And explain why it doesn’t have to be as painful as you may think.

The multi-entity problem is not what it looks like

The natural assumption is that multi-entity complexity is a big-company problem. But a 60-person business running three entities across two markets likely has harder reporting requirements than a 300-person company operating out of a single office.

It all comes down to structure. Multi-entity businesses have more transactions, but what really matters is the fact that they have more contexts. This means different legal structures, potentially different charts of accounts, different currencies, different approval requirements.

Research confirms that 79% of multi-entity businesses report persistent data silos, and 69% say they can't manage growth effectively without real-time visibility across entities (Intuit: How multi-entity complexity is reshaping CFO financial strategy).

These are problems that compound as the business scales. Each entity should be understood on its own terms, and all entities should be understood as part of the whole.

You need to zoom in and zoom out simultaneously

Rather than two different reports, finance teams at multi-entity businesses want one coherent view that lets them move fluidly between levels of aggregation. They should be able to group spend this quarter, break it down by entity, then by department, then by project, all without rebuilding the analysis each time.

A group-level view tells you what happened, and segmentation tells you why. The ability to move between the two is the basic requirement for making informed decisions.

And yet most multi-entity businesses don't have this. What they have is a manual consolidation process at month-end, where they have to pull entity-level exports, reconcile them against each other while translating between taxonomies that were never designed to match. Without the right infrastructure, there is a huge bottleneck in allowing businesses to make these comparisons.

(Side-by-side: Manual consolidation vs infrastructure model)

Dimensions are what make data meaningful

Dimensions are the vocabulary that turns a transaction into something useful. For example, proper dimensions turn "€4,200 spent in March" into "€4,200 spent on the Amsterdam product launch, charged to the marketing cost centre, against the Q2 events budget."

The first thing to note is that most reporting failures don’t start in the reporting layer. They actually start when a transaction lands without a project code, an invoice is processed with the wrong cost centre, or a reimbursement is submitted without team attribution.

Cost centres, projects, events, entities, billable client codes all need to be captured at the point of transaction, not reconstructed afterwards when someone goes to build a report.

Secondly, but equally important, is the fact that the same taxonomy needs to work consistently across all spend types. The same project code should apply to a card transaction, a supplier invoice, and an employee reimbursement. When each spend type has its own tagging logic, cross-dimensional analysis becomes structurally impossible without a manual join.

This is a common problem in tools that grew up as card products and then bolted on invoicing later (see our recent article on breaking up with your legacy card provider). By comparison, Moss is built so that the same dimension taxonomy applies across cards, invoices, and reimbursements, across different entities.

The data is only useful if it can leave the building

Spend per headcount. Marketing cost per qualified lead. Project profitability once labour, software, and travel are combined. These are the questions finance and commercial teams actually want to answer.

Unfortunately, none of them are answerable from spend data alone. They require blending spend with headcount data, pipeline data, project data, all of which lives somewhere else in your business’s tech stack. Hence why BI integration and API access have become true essentials for complex businesses.

This is the difference between a spend tool and spend infrastructure. The former gives you reports on the data that lives inside it. Pretty standard functionality for any platform that produces its own first party data. The latter gives other systems reliable, structured access to spend data.

That reliability starts in the product itself. Moss is built for multi-entity natively, providing the same spend types, the same dimension taxonomy, the same approval logic across every entity, with entity switching built into the product. When the data comes out through the API, it's already structured consistently, meaning you're not normalising chaos downstream.

“We're seeing finance teams want their spend data in the same ecosystem as their AI tools. The Moss API is part of what makes that connection possible.”

- Helen Fan, Staff Product Manager API & MCP

An effective API should expose not just transaction amounts but dimensions, accounting attributes, supplier data and entity structure; the ability to feed Power BI, Looker or BigQuery directly; and automated SFTP delivery for teams running file-based pipelines.

This is invaluable for smaller finance teams with complex setups, who need to quite literally do more with less.

(All spend types flow through the Moss API as a single, consistently structured data source, ready to feed your BI layer, ERP, or custom pipelines)

Where simpler tools run out of road

Most spend management products were built to solve one problem well, e.g. replace paper expenses, give visibility on card spend, get transactions into the accounting system faster. This is enough for a single-entity business with a manageable setup but, once the business grows, these tools often can’t follow.

The most common failure mode is fragmentation, where cards live in one tool, invoices come in through email or a separate AP system, and reimbursements are managed in a spreadsheet. Each has its own data model, tagging logic, and export format. And pulling them together requires a manual reconciliation process that's time-consuming, error-prone, and completely invisible to any BI layer downstream.

The second failure mode is rigidity. Many spend tools offer reporting, but fixed-format reporting built around the vendor's assumptions of what the average user needs. The moment a team needs a custom dimension or a cross-entity view, they hit a wall. These edge cases weren't prioritised because the tool was built for a simpler customer.

These failures are a result of building for simplicity. The businesses that outgrow these tools weren't wrong to use them early on. But they have to live with the consequences if they don’t upgrade further down the line.

“LI.FI is a great example of a Moss customer that’s using the Moss API to take their finance workflows to the next level. They used it to connect their spend data into Claude, and suddenly their finance team had real-time, cross-entity visibility through natural language with no manual exports, no manual reconciliation.”

- Helen Fan, Staff Product Manager API & MCP

Infrastructure is what other things are built on top of

Companies that struggle with multi-entity reporting tend to think they have a reporting problem, when what they really have is an infrastructure problem.

The distinction matters because the fix is completely different. You can't build a reliable dashboard on top of inconsistent, fragmented data. You just get a better-looking version of the wrong answer.

Good spend infrastructure covers the full surface area: cards, invoices, reimbursements, all tagged with the same dimensional structure regardless of how the money left the business. With Moss, that structure is native to the product. It provides multi-entity support with entity switching and a consistent dimension taxonomy built in, not bolted on. It integrates cleanly with the ERPs where the data needs to land. And it's open, meaning API access, structured exports, and data a BI team can actually work with.

Check out our customer story with LI.FI to see how they unlocked the true power of their spend data with Moss’ API.