Multi-entity operations are where PSA evaluations most often surface the gap between what a vendor demonstrates and what a platform actually delivers in production. Most platforms can handle a single entity cleanly. The architectural differences show up the moment you add a second legal entity with its own currency, cost center hierarchy, and GL mapping, and ask the system to route costs and revenue correctly between them without manual journal entries. Evaluating a PSA for multi-entity use requires a structured approach that goes beyond a standard demo checklist — and the questions you ask in the evaluation will determine whether you discover the limitations before or after go-live.
Start With Your Entity Structure, Not the Vendor’s Demo
The first step in any multi-entity PSA evaluation is to document your own entity structure before you open a vendor conversation. That means mapping every legal entity, the relationships between them, how cost centers are organized within each entity, which GL each entity uses, and which currency each entity invoices and reports in. Most firms discover during this exercise that their structure is more complex than they had assumed, particularly if the firm has grown through acquisition.
Once that map exists, you can test whether a platform models it natively or requires workarounds. The critical question is not whether the platform supports multi-entity in principle — all enterprise PSA vendors claim this — but whether your specific entity structure can be configured without custom development or data manipulation. Bring the map to the first vendor call and ask them to walk through it explicitly. If they need to schedule a follow-up to answer how cost center hierarchies would work across your entities, that is a signal.
Inter-Company Billing and Cross-Entity Cost Routing
For firms where consultants in one entity regularly deliver work billed by another, inter-company billing is the most operationally complex requirement to evaluate. The core question is whether the platform can model the transaction natively, where one entity records a cost and another records revenue, or whether the finance team needs to create manual journal entries to reconcile the two sides of the transaction at month-end.
Cost-Plus vs. Market-Rate Inter-Company Models
Different firms handle inter-company pricing differently. Some bill at cost plus a fixed markup. Others transfer at market rate. A few use a hybrid depending on the practice or geography. Enterprise PSA needs to support whichever model your finance team has defined, configured once at the entity or engagement level, not re-entered transaction by transaction. Ask vendors to demonstrate a live inter-company scenario using your own billing model, not the default example in their standard demo environment.
Audit Trail Across Entities
Regulators and auditors increasingly expect a complete, traceable record of inter-company transactions. When a consultant in one entity delivers work invoiced by another, the platform should maintain an auditable chain from time entry through cost allocation, billing, and GL posting without gaps or manual interventions. Platforms that handle inter-company through workarounds or manual exports break this chain and create audit risk that finance teams discover at the worst possible time.
Multi-Currency Handling and FX Revaluation
Multi-currency is another area where the gap between claimed capability and actual behavior is wide. Most enterprise PSA platforms can invoice in multiple currencies. Fewer handle the full lifecycle correctly: engagement currency separate from company reporting currency, FX revaluation on open AR balances at period-end, realized and unrealized gain and loss tracked in the GL, and consolidated reporting in a single base currency across all entities.
Example: A 280-person management consultancy operates entities in the US, Germany, and Singapore. The US entity invoices in dollars, the German entity in euros, and the Singapore entity in both dollars and Singapore dollars depending on the client. At month-end, the CFO needs a consolidated P&L in dollars with FX gains and losses correctly separated from operating margin. A platform that cannot produce this without a manual Excel consolidation is not ready for this firm’s multi-currency requirements.
During evaluation, ask vendors to demonstrate period-end FX revaluation on an open AR balance and show how the realized gain or loss posts to the GL. This single scenario reveals more about true multi-currency maturity than any product slide.
Hierarchical Permissions and Data Access Across Entities
Multi-entity operations require a permission model that matches your organizational hierarchy. Finance directors in one entity should see financial data for their entity only. Regional heads may need consolidated visibility across several entities. A global CFO needs cross-entity reporting without restrictions. And operational staff should access only the projects and cost centers relevant to their work.
Enterprise PSA handles this through cost center-based permission hierarchies, where access rights are granted at a point in the organizational tree and inherited downward. A user with access to the European regional cost center inherits visibility into all entities and practices below it, without needing individual configuration for each. Action-based permissions control what users can do — create engagements, maintain billing rules, run reports — while data-based permissions control what information they can see when they do it. Evaluate whether the platform’s permission model can replicate your org chart without requiring workarounds for each edge case in your structure.
Consolidated Reporting Across Entities
The reporting requirement for multi-entity operations is deceptively demanding. Finance wants consolidated margin by practice across entities. The COO wants utilization by region regardless of which entity owns the engagement. The board wants revenue by client across all entities in a single view. Each of these requires the platform to aggregate data across entity boundaries, apply currency conversion consistently, and present the result without requiring the analyst to build it manually in a BI tool.
Evaluate this by asking vendors to run three specific reports in their live environment: consolidated revenue by entity in base currency for the prior quarter, project-level profitability across entities for a named client, and utilization by role across all entities for the current period. If any of those reports require a data export or manual assembly, document the gap and assess whether your BI tool can close it through a structured data feed from the PSA.
The Demo Questions That Reveal the Most
Standard demos show what works well. These questions surface what does not:
- Show me an inter-company transaction from time entry to GL posting in both entities, without any manual steps. If the demo requires a pause or a “we’d configure that separately,” the platform relies on workarounds.
- Show me period-end FX revaluation on an open AR balance and how the gain or loss posts to the correct GL account. This separates platforms with real multi-currency architecture from those that simply display invoices in multiple currencies.
- Show me how a cost center permission change in one entity affects data access for a user who spans two entities. This reveals whether the permission model is genuinely hierarchical or requires individual configuration per user per entity.
- Show me consolidated utilization across all entities for the current period, produced directly from the platform without a data export. This tests whether cross-entity reporting is native or dependent on a BI layer that the vendor controls.
