A project controller at a mid-size engineering firm spends the third week of every month reconciling subcontractor invoices against timesheets in a spreadsheet, because the vendor invoice that lands in accounts payable has no native connection to the hours a contract welder actually logged against a task. She cross-checks rates, dates, and task codes by hand, then emails the project manager to confirm before anything gets marked ready for payment. That reconciliation gap is exactly what general availability of subcontractor vendor invoice matching to actuals in Dynamics 365 Project Operations, reached this September as part of 2026 release wave 1, is meant to close. For any organization running resource-based or nonstocked subcontracting through Project Operations, this is worth a close look before the next AP cycle, not because the concept is new (a version of automatic matching has existed since 2022), but because the field-level logic determining whether a match actually happens is stricter, and less forgiving, than most implementation teams assume going in.
What subcontractor vendor invoice matching actually changes
Subcontract-based project delivery in Project Operations has always followed a familiar shape: a project manager creates a subcontract against a vendor, attaches purchase price lists, links time-based or expense-based subcontract lines to either generic team members (to represent a staffing need) or named contract workers (to draw down capacity), and lets subcontractor resources log time, expenses, or product usage against tasks. Once that work is approved, it generates project cost actuals priced from the subcontract’s purchase rate. None of that is new. What the newly GA capability changes is the connective tissue between those cost actuals and the vendor invoice line items that eventually get paid.
Before this feature matured, matching a vendor invoice line to the underlying cost actuals was either manual or dependent on earlier, more limited automatic-association logic. Now, when a project manager records a vendor invoice with a line referencing a subcontract, Project Operations attempts to associate matching cost actuals automatically, and gives the project manager a structured, auditable workflow (built around a Verification status field) to confirm, adjust, or reject those matches before the invoice becomes eligible for payment.
The match logic: what has to line up
This is the part implementers need to internalize before go-live, because it determines whether the automatic matching actually fires or silently leaves everything to manual review. For a cost actual to link to a vendor invoice line, two separate conditions both have to hold.
The first is a status condition: the cost actual’s Adjustment status field must be blank. If a cost actual has been recalled, if its approval was cancelled, or if a correction journal against it is in progress, it is excluded from matching entirely, and the system will not surface it as a candidate no matter how closely the other fields align. This one trips up teams during parallel testing more than any other rule, because test data frequently includes actuals that went through a correction cycle, and those actuals simply never appear in the unmatched list, with no error message explaining why.
The second is field equivalence, and this is the longer list: project contract, project contract line, transaction class, project, task, resource category, transaction category, product, subcontract line, and bookable resource. Every one of these fields on the vendor invoice line has to match the corresponding field on the cost actual for a link to be proposed. There is one important carve-out worth building into your test plan: if a field is simply not populated on the vendor invoice line, it is excluded from the comparison rather than treated as a mismatch. That sounds like a convenience, and in some cases it is, but it also means a sparsely populated invoice line can match against a broader set of cost actuals than a fully populated one would, which is not always the outcome an AP team expects when they are trying to enforce tight three-way matching discipline.
Verification status: the workflow project managers actually see
Once matching candidates exist, the project manager works through a Verification status field that moves through three states. Not started is the default state for a fresh vendor invoice line, and it is the only state in which the line remains freely editable. The moment the first cost actual is matched to that line, status automatically advances to In progress, and the line locks against further direct edits outside the matching interface itself. From In progress, the project manager reviews the matched actuals in a grid, can pull in additional unmatched actuals or remove ones that were matched incorrectly, and once satisfied, sets the line to Complete, either manually or through the system’s own completion logic once every actual on the line has been addressed. Only when every line on a vendor invoice reaches Complete can the invoice itself be confirmed, and confirming it is what flips the invoice to Ready for payment, reverses the previously recorded project cost actuals, and books the actual cost from the vendor invoice onto the project instead. That last step matters for anyone reconciling project cost reports mid-cycle: costs on a project can genuinely shift in value between the point a subcontractor’s time is approved and the point the corresponding invoice clears verification, and finance teams need to know that is expected behavior, not a data integrity problem.
Unmatching works, but only in one direction of the workflow. A project manager can select one or more linked cost actuals from a vendor invoice line’s Matched cost actuals tab and unmatch them, but only while that line sits in In progress status. Once a line reaches Complete, unmatching is no longer available through the standard interface, which is a deliberate control: it keeps a verified invoice from being quietly altered after AP has already relied on that verification to release payment.
Implementation considerations before rollout
A few practical points are worth working through with the project accounting team before turning this on for a live subcontracting population. Fixed Price billing is not currently supported for resource-based or nonstocked subcontracting scenarios, so any subcontract lines built around milestone-based fixed pricing need a different reconciliation approach; automatic matching in this feature applies to time-and-material subcontract lines where cost actuals are generated from logged, approved work. Teams that run a mix of fixed-price and time-and-material subcontracts on the same project should map out, line by line, which subcontract lines are even eligible for automatic matching before assuming full invoice coverage.
It is also worth auditing how consistently your existing vendor invoice entry process populates the ten matching fields. If your AP team has historically entered vendor invoice lines with only project and transaction class filled in, and left task, resource category, or bookable resource blank as a matter of habit, the matching engine will happily use whatever partial field set is present, and the practical effect is a much looser match than your controls team may assume is happening. Before rollout, walk through a sample of recent invoices with both project accounting and AP to agree on which fields will be entered consistently going forward, because the strictness of this feature is only as good as the discipline behind the data feeding it.
Finally, because this capability reached general availability in the same month as several other Project Operations updates, including changes to correction journal usability and project accrued revenue reconciliation, it is worth testing subcontractor invoice matching in a sandbox environment that reflects your current configuration rather than assuming behavior documented earlier in the release wave still applies unchanged. Microsoft’s release cadence for Project Operations has been dense enough this year that features shipped in preview back in May have, in some cases, had their default behavior refined by the time they reached GA in September.
Organizations that get the field discipline right stand to remove a genuinely manual, error-prone step from project-based AP, and the audit trail built into the Verification status workflow gives finance a defensible record of exactly which actuals supported each payment decision. Routeget’s implementation teams have walked several clients through exactly this kind of subcontract reconciliation redesign, and the pattern holds consistently: the technology is ready well before the underlying data entry habits are, and that gap is where rollout timelines usually slip.
#SubcontractorInvoiceMatching #ProjectOperations #DynamicsFinanceOps #ProjectAccounting #VendorInvoiceReconciliation #ERPGovernance