Findings from a live Dynamics 365 Finance + Project Operations implementation, documented for other consultants and clients who may be hitting the same wall.
Overview
Dynamics 365 Project Operations (PO) is designed to integrate seamlessly with Dynamics 365 Finance for vendor invoice postings tied to projects. In principle, Finance posts the vendor invoice, and Project Operations picks up the line-level detail to create the corresponding project actual.
In practice, we’ve identified two integration behaviours where Project Operations does not faithfully reflect what Finance has posted — one where it silently overrides the value Finance sent, and one where it rejects a perfectly valid invoice line outright. Both have real financial and operational consequences if left unaddressed, and both are currently raised with Microsoft, with a resolution pending.
This post walks through each issue, a worked example, the business impact, and — importantly — a control we’d recommend every team running this integration put in place immediately: a monthly reconciliation of the Project Integration account.
Issue 1: Project Operations Recalculates the Vendor Invoice Line Value on Confirmation, Overriding Finance
What happens
When a vendor invoice is integrated from Dynamics 365 Finance into Project Operations, Project Operations initially accepts the invoice line value passed across from Finance. However, during the confirmation process, Project Operations independently recalculates the line value rather than preserving the value Finance originally posted.
Where it breaks down
This becomes a serious problem specifically when a discount and/or a price unit has been applied on the Finance side. Price unit is not a niche or custom setting — it’s standard Dynamics 365 functionality, available directly on the Purchase Order / Vendor Invoice form, used routinely to post pricing in units other than 1 (e.g., price per 100, price per 1,000).
Project Operations has no price unit field at all. The concept simply doesn’t exist in its data model for the vendor invoice/actual entity. So when Finance posts a line with a price unit other than 1, Project Operations has no way to receive or represent that value — its confirmation-time recalculation logic effectively assumes a price unit of 1 by default, which is why the recalculated value it lands on can differ dramatically — and silently overrides — the value originally posted and confirmed in Finance.
Worked example
| Field | Value |
|---|---|
| Quantity | 500 |
| Unit price | £1,000 |
| Price unit | 100 |
| Net value posted in Finance | £5,000 |
| Value of the actual created by Project Operations | £500,000 |
Finance correctly calculates the line as (Quantity ÷ Price unit) × Unit price = (500 ÷ 100) × £1,000 = £5,000.
Project Operations, on confirmation, has no field to receive the price unit of 100 and effectively recalculates as Quantity × Unit price = 500 × £1,000 = £500,000 — a 100x overstatement against what Finance posted.
Why it matters
Finance is the system of record for the posted vendor invoice value. When Project Operations recalculates and overrides that value during confirmation:
- Project actuals, WIP, and cost postings become materially misstated — in this example, by two orders of magnitude
- Project profitability and billing calculations built on those actuals are unreliable
- The discrepancy is silent — there’s no error, warning, or block. The invoice integrates “successfully,” just with the wrong value
- Reconciliation between Finance and Project Operations becomes essential, not optional, wherever discount or price unit is used
Issue 2: Project Operations Rejects Vendor Invoice Lines With a Zero Unit Price — Even With Valid Quantity and Net Amount
What happens
Project Operations fails to integrate a vendor invoice if any line on it has a unit price of zero, even when that same line carries a valid, non-zero quantity and net amount.
Why it’s a problem
A zero unit price combined with populated quantity and net amount is a perfectly valid and accepted posting pattern in Dynamics 365 Finance. It’s not bad data, and it’s not something Finance flags or blocks. Project Operations’ integration logic, however, treats a zero unit price as a blocking condition, causing the entire invoice line to fail integration.
Worked example
| Field | Value |
|---|---|
| Quantity | 79 |
| Total cost | £15,489 |
| Unit price | (blank — not entered) |
£15,489 ÷ 79 resolves to a long recurring decimal. Rather than force an imprecise, rounded unit price into the system, Finance simply leaves unit price blank — this has no impact on the accounting or the posted value; quantity and net amount fully define the line.
Project Operations, on integration, sees unit price = 0 and rejects the invoice line outright — meaning the invoice never makes it into the project’s actuals at all.
Worse still, the invoice doesn’t show up anywhere it can be traced. It doesn’t appear in project actuals, and it also cannot be found in the Project Operations integration workspace — there’s no visible failed/errored record pointing back to it. From a Project Operations perspective, the invoice simply doesn’t exist. The only way to know it’s missing is to independently compare what was posted in Finance against what landed in Project Operations.
Why it matters
This isn’t an edge case that can be worked around by “fixing the data” upstream:
- Finance itself accepts, posts, and closes the period on these lines without issue
- Unit price is effectively a derived/display convenience in Finance, not a mandatory field for posting — Project Operations’ integration logic treats it as mandatory, which is a genuine gap in how the two systems define a “valid” invoice line
- The failure mode here is arguably worse than Issue 1: instead of a silent value mismatch, the invoice doesn’t integrate at all — and leaves no trace in the integration workspace — meaning project actuals are understated by the full missed invoice value, with no built-in signal that anything failed, until someone notices it’s missing
Current Status: Raised With Microsoft
Both issues have been formally raised with Microsoft, and we are currently awaiting a response / resolution. This post will be updated as soon as we hear back, and we’ll follow up with confirmed root cause and fix details (or supported workarounds) once available.
If you’re running into either of these issues on your own implementation, it’s worth raising a support ticket referencing similar behaviour — the more cases logged, the more likely this gets prioritised.
Known Limitation, Bug, or Configuration Gap?
Before raising these with Microsoft, we checked whether either behaviour was already documented as a known issue, a published limitation, or a config setting we’d missed. Here’s what that review turned up:
- No price unit field exists anywhere in the Project Operations vendor invoice line schema. Microsoft’s own dual-write documentation confirms that on the Finance side, vendor invoice lines require unit price, unit of measurement, and quantity — standard fields on the Purchase Order / Invoice form. But across every published version of the
msdyn_projectvendorinvoicelinesdual-write map — introduced at version 1.0.0.6 in the February 2024 release, and unchanged in every release since, including the most recent (July 2026) release — price unit never appears as a mapped or supported field. This points to Issue 1 being a genuine data model gap — Project Operations was never built to receive a price unit — rather than a misconfiguration on our side, a regression, or something already fixed that we’ve missed. - Neither issue is listed by name in any published “What’s New” or quality-update release note, checked across every release cycle from August 2023 through July 2026 (the most current published release at time of writing).
- Related — but distinct — fixes exist in the same functional area, which is worth flagging. The March 2026 quality updates include two subcontracting fixes that sit close to Issue 1’s territory: one resolves a duplicate-key error that occurs when actuals linked to a vendor invoice are re-evaluated at contract confirmation (Ref. 5556498) — the same confirmation-time re-evaluation step where our price-unit override happens, though this is a different specific defect (a duplicate-key error, not a value miscalculation); the other fixes the Subcontractor field not auto-populating on vendor invoice lines based on a subcontract line (Ref. 6000962). These confirm Microsoft has been actively patching defects in vendor invoice confirmation and subcontracting during 2026, which is encouraging, but neither fix touches price unit handling or the zero-unit-price rejection specifically.
- A related — but distinct — pricing gap is documented separately. Microsoft’s own guidance notes that a purchase price list is essential on the vendor/subcontract record, otherwise actuals are created with a zero cost amount. This confirms that pricing/cost handling at the Finance–Project Operations boundary is a recurring soft spot in this integration generally, even though it doesn’t cover either issue specifically.
- No LCS issue or community thread documents either behaviour, based on public sources. The standard first step when something like this surfaces is to check Microsoft’s LCS issue search for a known issue before raising a support incident — we did this against publicly available channels, found nothing matching either scenario, and proceeded to raise both directly with Microsoft Support. Note: Microsoft’s release notes point to project-specific LCS KB articles for granular bug-fix detail, which sit behind a gated, per-tenant system — so this review covers all publicly published documentation, not any private KB articles that may exist inside a specific LCS project.
Conclusion: both issues currently sit as undocumented gaps rather than acknowledged, published limitations — Issue 1 looks like a structural data model gap (no price unit field ever existed to receive Finance’s value), while Issue 2 looks like an integration validation rule that’s stricter than what Finance itself enforces. Until Microsoft confirms whether these are being tracked as bugs, treated as by-design limitations, or require a configuration change we haven’t identified, we’d treat both as known risks to actively monitor, not edge cases to deprioritise.
Recommended Control: Reconcile the Project Integration Account Every Month-End
Until Microsoft confirms a fix, do not rely on the integration running silently and correctly. We’d strongly recommend the following as a standing month-end control for any team running D365 Finance + Project Operations vendor invoice integration:
- Monitor the Project Integration account balance every month.
- If the balance is not zero, treat it as a signal — not noise. A non-zero balance can indicate:
- Value mismatches from Issue 1 (discount/price unit lines recalculated incorrectly)
- Missing invoices from Issue 2 (zero unit price lines rejected from integration)
- Other timing or integration failures unrelated to these two issues
- Investigate the difference before closing the period. Trace the variance back to specific vendor invoices and lines, and confirm whether it’s attributable to one of the two issues above or something else.
- Reconcile Finance-posted values against Project Operations actuals for any invoice involving a price unit, discount, or a zero/near-zero unit price, as these are the highest-risk patterns identified so far. Because Issue 2 leaves no visible trace in the Project Operations integration workspace, this comparison has to be done directly against Finance-posted invoices — don’t rely on the integration workspace alone to surface what’s missing.
- Document and correct as needed — manual adjustment, re-integration, or a journal correction depending on your process — before the project financials are reported on.
Treating this as a routine, non-negotiable month-end step will catch both issues (and likely others) before they compound across periods or distort project profitability reporting.
Summary
| Issue 1 | Issue 2 | |
|---|---|---|
| Trigger | Discount and/or price unit applied in Finance | Unit price = 0 with valid quantity & net amount |
| Behaviour | Project Operations has no price unit field, so it recalculates and overrides the value on confirmation | Project Operations rejects the invoice line from integration entirely |
| Failure mode | Silent — invoice integrates, but with the wrong value | Silent — invoice never integrates, and isn’t visible in the integration workspace either |
| Example impact | £5,000 in Finance → £500,000 in Project Operations | £15,489 valid invoice line never reaches project actuals |
| Status | Raised with Microsoft, response pending | Raised with Microsoft, response pending |
Both issues point to the same underlying theme: Project Operations’ confirmation and integration logic doesn’t fully respect the invoice line data contract that Dynamics 365 Finance treats as valid — whether that’s a computed value involving price unit and discount, or a valid-but-unusual value combination like a zero unit price.
Until Microsoft resolves this, the safest posture is proactive monthly reconciliation of the Project Integration account, rather than assuming the integration is complete and accurate by default.
Will update this post with Microsoft’s response once received.
Dynamics 365 Finance 
Leave a comment