What is Managed Margin?

Why show gross margin and Managed Margin separately?

The two layers answer different questions. Gross margin shows the approved project revenue basis after the project and commercial costs included in the product calculation. Managed Margin then shows what remains after a configured share of workspace-level shared cost is assigned to that purchase order.

Keeping the layers separate preserves traceability. A delivery lead can examine the direct project result without shared allocations obscuring it, while finance can add a controlled shared-cost perspective. If no shared cost is allocated to a project, Managed Margin equals gross margin.

Worked example: gross margin to Managed Margin

Assume a fixed-price purchase order with an approved budget of USD 200,000. Its included commission, labour, overhead, subcontractor, infrastructure, and other supported project costs total USD 120,000 after any supported revenue credits are applied. The resulting gross margin is USD 80,000.

The six-point difference comes entirely from the stated shared-cost allocation. It does not mean the project's direct delivery performance changed. The example also does not say whether USD 12,000 is the right allocation. That is a finance policy decision that needs an owner, rationale, and review cadence.

How does shared-cost allocation work in the product?

An authorised workspace user can create a flat shared cost and allocate a percentage of that cost to purchase orders in the same workspace. For example, if a USD 20,000 shared delivery-management cost is allocated 40% to one purchase order and 60% to another, their shares are USD 8,000 and USD 12,000.

The application calculates each purchase order's share from the shared cost value multiplied by its allocation percentage, then sums the allocated shares for that purchase order. A combined allocation over 100% produces a warning rather than a hard block, so finance still needs to reconcile the allocation total. Shared-cost detail is permission-controlled because it can expose sensitive financial information.

Extend the same example to see why that warning matters. If a third purchase order is later also allocated 30% of the same USD 20,000 shared cost, the workspace total reaches 130% (40% + 60% + 30%). Each purchase order still shows a calculated share – USD 8,000, USD 12,000, and USD 6,000 – but those three shares sum to USD 26,000 against a USD 20,000 shared cost that was only meant to be assigned once. Managed Margin flags the total rather than blocking the entry, so a finance owner still has to correct the allocation before any of the three purchase orders' Managed Margin figures can be trusted.

When is Managed Margin useful?

Managed Margin is useful when a firm wants a second internal view after selected central delivery costs, while preserving gross margin as the direct project layer. It can support questions such as:

• Which shared costs have been assigned to this purchase order?
• How much does the allocation change the dollar and percentage result?
• Are projects being compared using the same allocation policy?
• Has a shared-cost value or allocation changed since the prior review?
• Does finance need to correct an allocation total above 100%?

Use the metric with its underlying gross margin and allocation details. Do not compare one project's Managed Margin with another project's gross margin. Do not compare two Managed Margin percentages if the projects use different shared-cost policies without explaining the difference.

A practical review sequence

1. Confirm the approved budget and gross-margin cost basis.
2. Review the gross-margin amount and its direct cost drivers.
3. List each shared cost allocated to the purchase order.
4. Recalculate each share from value x allocation percentage.
5. Check total allocations across purchase orders for duplication or omissions.
6. Read the resulting Managed Margin only after those checks pass.

How do the two layers play out across a multi-phase software implementation?

Consider a systems integrator delivering a multi-phase software implementation for a client: discovery, build, and rollout, structured as three linked purchase orders under one program.

At program kickoff, finance allocates a share of a central program-management shared cost across all three phase purchase orders. Each phase's delivery lead reviews only their own gross margin day to day — the layer separation described above means a rework spike in the build phase does not silently change what discovery's numbers already reported.

Mid-build, the team adds a subcontractor to cover a skills gap. The subcontractor's cost lands in gross margin as a delivery cost, not as a shared-cost allocation, so the delivery lead sees it immediately in their own phase's margin. Keeping that distinction matters here: an allocation change is a finance decision with its own rationale, while a subcontractor cost is a direct delivery decision, and conflating them makes it hard to tell which lever actually moved the number.

Mid-program, the shared program-management cost gets re-allocated because the rollout phase needs less central oversight than planned. Run the practical review sequence above before accepting the new Managed Margin figure: confirm the approved budget and gross-margin drivers first, then check the shared-cost value and allocation percentages, because a re-allocation can move Managed Margin without any change to delivery performance. Treat these re-allocation checks as a scheduled event using the review cadence guide, not a one-off explanation after someone notices the number moved.

At program close, a governance report compares all three phases side by side. If one phase quotes gross margin and another quotes Managed Margin without saying so, the comparison breaks the rule above against mixing the two layers. Label every reported figure with its layer, not just its percentage, before it reaches a steering committee. None of this happens automatically: Managed Margin does not decide the allocation policy or reconcile it across phases on its own; a finance owner still sets and checks the shares.

What Managed Margin does not mean

The metric is not operating margin or net margin. It does not automatically include every central function, corporate expense, tax, financing cost, depreciation policy, or accounting adjustment. It is not a forecast of final project performance. Its result depends on the approved budget, the product's supported project-cost calculation, the shared costs finance configured, and the allocation percentages supplied.

It also does not establish how contract revenue should be recognised. IFRS 15, where applicable, governs revenue reporting based on contracts and performance obligations. Finance must keep statutory policy separate from this internal project-control view.

For the broader operating context, start with the professional-services project margin guide. For the base calculation, see how to calculate project margin; for aggregation, read how project margin rollups work.

Sources and methodology

• IFRS Foundation, IFRS 15 Revenue from Contracts with Customers. Used only to distinguish the internal product metric from statutory revenue recognition.
• UK Infrastructure and Projects Authority, Cost Estimating Guidance. Used for transparent assumptions, exclusions, ownership, and consistent breakdowns.
• The gross-margin, shared-cost-share, warning, and Managed Margin formulas were reviewed against the current product implementation on 24 August 2026. The example is synthetic.