Microsoft’s roadmap item 578900, “Deprecate transaction origins,” describes direct references on journal lines, actuals, and invoice-line details. These references would connect transactions to originating time entries, expenses, and material-usage logs while reducing the database operations needed to maintain those relationships.
What is planned—and what is already documented
The roadmap entry lists the feature as In development, with an April 2026 preview target and December 2026 general-availability target. Its stated scope is the Web platform, covering Worldwide Standard Multi-Tenant and GCC environments.
Those dates need careful interpretation. April 2026 has passed, but a preview month in roadmap metadata does not establish that the feature reached a particular environment. December 2026 remains a future target. Microsoft explicitly describes its roadmap dates as estimates and warns that feature information can change.
Microsoft Learn independently documents the technical foundation for this transition. Its transaction-origin guidance, covering Project Operations Integrated with ERP and Project Operations Core, describes a Source document lookup that can reference different types of originating records. Crucially, the same guidance says transaction-origin records continue to be created alongside that lookup. That documents coexistence, not completed retirement.
The practical message: do not treat the roadmap title as a signal to remove production dependencies immediately.
Why a source reference is not the whole transaction trail
Microsoft’s documented time-entry example illustrates the distinction:
- Submission creates cost and unbilled-sales journal lines.
- Approval creates cost and unbilled-sales actuals.
- Invoice creation produces an invoice-line transaction using the unbilled-sales actual.
- Invoice confirmation creates an unbilled-sales reversal and a billed-sales actual.
Transaction-origin records connect records across those stages. Microsoft also documents relationships associated with invoice corrections.
The architectural implication is worth separating from Microsoft’s stated functionality: locating the original document and reconstructing every intermediate relationship are different requirements. A direct pointer may answer “Where did this transaction originate?” without, by itself, proving that an existing audit report can reconstruct every relationship it previously followed.
That is why this apparently modest data-model change deserves a dependency review rather than a hurried find-and-replace exercise.
What administrators and developers should prepare
The following is a preparation checklist, not a Microsoft migration procedure:
- Inventory transaction-origin dependencies. Identify custom reports, integrations, queries, and automation that read these records or expect new ones to appear.
- Define what each dependency actually needs. Distinguish simple source-document navigation from full lifecycle reconstruction.
- Plan representative sandbox tests. Include submission, approval, invoicing, reversals, and corrections—not just a successfully posted transaction.
- Separate historical and new-transaction testing. Validate both older records and transactions generated after any relevant feature change.
- Require documented transition details before changing production. Confirm supported replacement behavior, applicable versions, and environment availability before retiring an existing integration.
These recommendations follow from the documented coexistence of source-document references and transaction-origin records; they are not evidence that a particular customization will break.
The boundaries that remain unclear
The available evidence does not establish an exact cutoff for transaction-origin creation, a migration tool, historical-row deletion, or a version-specific deployment sequence. Nor does it establish a measured performance improvement. Reducing database operations is the roadmap’s stated objective, not a published benchmark.
Microsoft Learn’s coexistence guidance was last updated on March 25, 2026, so it should be understood as the behavior described in that documentation rather than a guarantee about every subsequent rollout.
For Project Operations teams, the sensible response is preparation without panic: map the dependencies, define the traceability requirements, and validate the supported replacement when deployment details become clear. Fewer linking records may simplify the machinery—but the accounting trail still needs to arrive intact.