A UK consultancy signs a £400,000 statement of work. Two of the four people who deliver it are employed by a sister entity in Poland, and a third is a contracted specialist invoicing monthly. Everyone knows the engagement is profitable. Nobody can say by how much until six weeks after it ends, when finance finishes reconciling inter-entity charges against timesheets and vendor bills. That lag is not a reporting failure — it is a design decision made when the platform was configured. This piece sets out what a professional services ERP has to model for a firm that delivers through a network, and which decisions cannot be deferred.

A London firm signs the statement of work. The people who deliver it sit in Kraków, in Porto, or inside a partner firm one contract removed from the client. For UK consultancies and outsourcing providers this is the normal shape of delivery, and it is the hardest thing to represent honestly in a finance system.

The problem is not invoicing the client. It is that cost accumulates in one set of books while revenue is recognised in another. The UK entity holds the contract; the delivering entity carries the payroll and the subcontractor bills. Until those two records meet, the margin on an engagement is an estimate. In many firms they meet in a spreadsheet after the period closes, maintained by one person in finance who reconciles hours against inter-entity charges and vendor invoices.

That reconciliation produces a number nobody can act on. By the time it lands, the engagement is either finished or too far along to reprice.

Inter-entity charging and subcontract management are settled when the platform is configured — not bought afterwards as an add-on. A professional services ERP either carries the delivery network in its posting rules or hands the work back to finance every month.

Dynamics 365 Project Operations ships in three deployment types: Project Operations Core, Project Operations Integrated with ERP, and Project Operations for manufacturing.

Project Operations Core stops at proforma invoicing. The proforma is reviewed and sent to a separate financial system for processing, and expense handling covers basic project-based expenses. Microsoft’s own description of the deployment assumes a third-party ERP for sales taxes, exchange rates, reimbursements and non-project expenses. For a firm that already runs finance elsewhere and wants resourcing, scheduling and time capture, that is a defensible place to stop.

The integrated deployment closes the loop. It adds configurable project cost and revenue profiles, rules for work in progress accounting and accruals, and project revenue recognition that Microsoft documents as IFRS-compliant. Invoicing runs on the enterprise sales tax and date-effective exchange rate engine behind Dynamics 365 Finance.

This is the first real fork in a professional services ERP selection, and it is a cleaner question than vendors usually make it: does finance belong inside the same system as delivery, or next to it? For a networked firm the answer decides everything downstream, because inter-entity cost and recognised revenue only land in the same ledger under the integrated deployment. Firms that do not need the finance and operations footprint run project work in Dynamics 365 Business Central instead, where it sits in the Projects module.

Microsoft’s term for shared delivery is the lending and borrowing legal entity. The entity holding the client contract borrows; the entity whose people do the work lends. Resources in the lending entity book time and expense directly against projects owned by the borrowing entity, and that single mechanic is what separates a network reporting continuously from one reconciling monthly.

Two settings govern the money. Cost records at the borrowing entity’s unit cost price list, so the delivering entity’s books carry the rate the contracting entity is charged rather than a rate invented at period end. The margin retained by the delivering entity comes from a transfer price, defined per borrowing legal entity with an effective date — which makes a rate change a dated record instead of a renegotiated spreadsheet.

Intercompany invoicing then runs as a posting chain. The lending entity creates the intercompany customer invoice, manually or through a periodic batch, and posting it creates the corresponding pending vendor invoice in the borrowing entity. Costs reach the borrowing entity’s project subledger when that vendor invoice is posted. Before any of it works, intercompany accounting has to be configured for each pair of legal entities, which is worth raising during scoping: how many pairs, and who maintains them as the group changes shape.

What intercompany invoicing gives a delivery director is a chain of records with named owners at each step. What it demands in return is that someone decides the transfer price deliberately, in advance, for every entity pair.

Contracted specialists are the other half of the network, and they usually arrive through procurement rather than resourcing. A subcontract created in Dataverse generates a purchase order in Finance; each timesheet or expense the subcontractor records creates a product receipt; when the vendor invoice arrives, the accounts payable clerk matches it against the recorded time and expense using three-way matching. Subcontract management stops running parallel to the project record and becomes part of it.

Licensing follows the resource type. A subcontractor set up as a bookable resource of type User enters their own time and needs a valid licence. Types Contact and Account can be scheduled and booked on projects without any access to the system. For a firm that books forty associates a quarter and wants ten of them typing into it, that distinction is a line in the budget.

One documented limit belongs in the conversation before contracts are drafted: fixed-price subcontracts are not supported for resource and non-stocked scenarios in Dynamics 365 Project Operations. Subcontract lines are quantity-based or work-based. A firm that buys fixed-price packages from delivery partners should agree how those are represented during design, not during UAT.

OntargIT built the project-accounting layer for Room 8 Group, an international game-development outsourcing company, on Dynamics 365 Finance and Operations: project accounting, project invoicing, financial consolidation, revenue recognition at completion, and an integration between Jira and Dynamics 365 so that the delivery record and the financial record describe the same work. OntargIT also works from the other side of the arrangement, delivering 17 joint projects as the subcontracted partner to Inciper Limited, a UK Dynamics 365 consultancy.

The delivery network is the part of a services firm that a platform either models or ignores. Transfer prices between entities, the posting chain that carries cost from the delivering books into the contracting books, and the route by which a subcontractor’s hours become a matched vendor invoice are all set during implementation — and all expensive to unpick afterwards. Test a shortlist against the way your firm actually staffs work, not against the org chart.