Offshore and multi-entity delivery models in Project Operations

By Emil Björk · Microsoft business apps consultant, Gothenburg

How to run offshore and nearshore delivery on Dynamics 365 Project Operations — resource company versus contracting company, intercompany time and transfer pricing, calendars, currencies and rate cards, approvals across entities, and when a single legal entity with cost centres is the smarter design.

Updated 2026-09-02

A consulting firm with a delivery centre in another country has one commercial contract and two legal entities doing the work. The client is invoiced by the onshore entity; half the hours are logged by people employed by the offshore entity; somebody has to move cost and margin between the two in a way tax authorities accept. Dynamics 365 Project Operations has a model for this, but it only exists in one deployment mode, and the model is easy to over-engineer. This guide covers the mechanics and the design choices that matter more than the mechanics.

The two-entity model

Project Operations distinguishes the contracting company — the legal entity that owns the project contract and invoices the customer — from the resource company, the entity that employs the person doing the work. A resource from the offshore entity books time to a project owned by the onshore entity. Behind the scenes, the time creates an intercompany transaction: cost in the resource company, an intercompany charge to the contracting company at a transfer price, and revenue to the customer from the contracting company at the sales rate.

This is available in the Project Operations with Finance and Operations deployments, where the F&O project accounting module holds the intercompany setup: intercompany customer and vendor pairs between the entities, transfer price lists, and the periodic intercompany invoicing process. The deployment types guide explains why this matters; the short version is that the Lite deployment does not do intercompany, and a firm on Lite with an offshore entity ends up reconciling between two systems.

Setting it up

  • Legal entities and intercompany pairs. Each delivery entity is a vendor to each contracting entity and each contracting entity a customer to each delivery entity. For three entities that is six pairs; for eight, it is fifty-six. Most firms restrict which entities can actually loan resources to which, and should.
  • Transfer price lists. A cost price list per resource company and contracting company pair, by role and optionally by resource, in the contracting company's currency. This is the number the tax team cares about; agree it with them, document the basis, and change it only with a paper trail.
  • Resource setup. Each bookable resource belongs to one company. Work-hours calendars carry the resource's local holidays and hours, which is what makes capacity and utilisation honest across time zones.
  • Rate cards for the customer are unaffected: the sales price list on the contract is the contracting company's, in the contract currency, regardless of who delivers.
  • Approvals. Time is approved by the project manager in the contracting company, which is usually right; expense claims are often approved locally for policy reasons. Both are configurable.

The monthly flow

Time and expense post as actuals in both entities. Period end, the contracting company runs project invoicing to the customer as normal. The resource company runs intercompany invoicing, generating a vendor invoice in the contracting company and a customer invoice in the resource company for the transferred hours at the transfer price, in the appropriate currencies. Margin in the contracting company is sales minus transfer price; margin in the resource company is transfer price minus cost. Group margin is the sum, and the intercompany eliminates on consolidation.

The order matters: post all time, invoice the customer, run intercompany. Firms that run intercompany invoicing before all time is posted chase catch-up invoices for months.

Practical complications

Currencies. The resource company's cost is in its currency, the transfer price is usually in the contracting company's, and the customer contract may be in a third. Exchange-rate timing for the intercompany invoice — transaction date or invoice date — should be fixed in the intercompany parameters and agreed with finance once.

Time zones and calendars. A resource in a time zone nine hours ahead logs Friday's work that the onshore approver sees on Thursday. This is cosmetic in the product but confuses approvers; put a day's grace into the approval expectation. Public holidays differ; the calendars must be per country or capacity is wrong.

Expenses. Offshore expenses are typically reimbursed locally and re-charged at cost. Whether they route through the intercompany process or are handled as a separate recharge is a policy choice; the product supports both, and the second is simpler.

Tax. Cross-border services can carry withholding tax or reverse-charge VAT on the intercompany invoice. That is F&O tax configuration, not Project Operations, and it must be set up on the intercompany customer and vendor accounts before the first invoice.

Data residency. A Dataverse environment lives in one region. A firm whose offshore entity's regulator expects local data storage needs that conversation before choosing the tenant region, not after.

The alternative: one entity, cost centres

Not every firm needs the two-entity model in the system. If the offshore centre is a branch rather than a separate company, or if statutory accounts for it are simple enough to derive from cost centres, run one legal entity with resources tagged by financial dimension. Time flows to the project with the resource's cost; margin reporting by delivery centre comes from the dimension; there is no intercompany to run. Firms regularly pick the two-entity model because it looks correct and then find the intercompany process is the most fragile part of their close.

The test: does a tax authority or auditor require an intercompany invoice between these two entities? If yes, model it. If the answer is "we might want the reporting", use dimensions.

Where partners come in

Automated transfer-pricing documentation, mark-up calculations tied to cost-plus methods, and multi-tier delivery chains (offshore entity subcontracting to a fourth) are beyond the standard process and usually handled with a small extension or a partner accelerator. Subcontracted offshore vendors — a separate company you do not own — are not intercompany at all; the subcontracting in Project Operations guide covers that path.

Further reading

Related guides

Spot something wrong or want a topic covered? Send a correction or a topic request — both are welcome.