How a Leading North American Commercial Vehicle Manufacturer Prevented Incorrect Purchase Prices on Purchase Orders Using Dynamics 365 Finance & Operations

For growing businesses running Dynamics 365 Finance & Operations, procurement accuracy is non-negotiable. As order volumes climb and vendor pricing evolves, even a small gap in how purchase prices are managed can quietly erode margins, trigger invoice disputes, and undermine trust in the system. One of the most common and most overlooked – causes of pricing errors on Purchase Orders is something surprisingly simple: outdated trade agreement records that were never closed.

Have you ever updated a vendor’s price in D365 FO, only to find that Purchase Orders raised the next week still show the old price? If you’re nodding, this article is for you.

Consider this: organisations that leave overlapping trade agreement records unmanaged often find hundreds – sometimes thousands – of duplicate active price records for the same Item × Vendor combination in their PriceDiscTable. Each one is a potential pricing conflict waiting to surface on a Purchase Order. The cumulative effect on procurement accuracy, AP reconciliation time, and vendor relationships is significant.

By the end of this article, you will understand exactly why this happens, how D365 FO’s price engine actually resolves trade agreements, and the single rule that eliminates the problem entirely.

Why This Matters

Incorrect purchase prices on POs are not just a data nuisance. They lead to overpayments that chip away at margins, invoice mismatches that clog up Accounts Payable, and worst of all – procurement teams who stop trusting the system and start overriding prices manually on every order. Once that happens, the entire value of centralized pricing governance is gone.

Why We’re Writing This

At CloudFronts, we’ve implemented and supported Dynamics 365 F&O procurement modules across manufacturing, distribution, and services organisations. This specific issue – stale trade agreements causing wrong PO prices has come up in nearly every engagement where vendor prices are managed through the Trade Agreement Journal. We’ve seen the pattern, diagnosed the root cause repeatedly, and built the automation to prevent it. This article distils that experience into something actionable.

How D365 FO Resolves Purchase Prices

The price on a Purchase Order line does not come from the item master. It is resolved from a Trade Agreement – a dated record that says: “For this item, from this vendor, in this currency, starting from this date, the unit price is X.” These records are created through the Trade Agreement Journal, posted, and stored in the PriceDiscTable.

When a PO line is created, the price search engine finds every posted record whose date window (From Date to To Date) covers the PO date, filters by matching keys (item, vendor, currency, site, warehouse, quantity break), and selects the price. Critically, the system does not prefer the most recently posted record. It looks at date windows. If two records both covers today, the engine has two valid candidates – and its tie-breaking behaviour is not something you should rely on for pricing accuracy.

The Problem: Overlapping Records

Here’s how the issue plays out. A vendor price is loaded into D365 FO – either from a legacy system integration or manually by a buyer. The record is created with an open-ended To Date (the sentinel 1900-01-01 or a far-future date), meaning it never expires.

Months later, a new negotiated price arrives. A fresh trade agreement line is added for the same Item × Vendor. But nobody closes the original record. Both records now have date windows that include today. The price engine finds two matches, and sometimes the older, stale price wins.

Root cause: there is no closure step. Every new price is layered on top of the old one instead of replacing it in time.

The Fix: Close Before You Create

The rule: Whenever a new price record is created for an Item × Vendor combination, the currently active record must have its To Date set to Today − 1. The new record’s From Date is set to Today. This produces two non-overlapping windows – old price valid up to yesterday, new price effective from today.

Why Today − 1 and not Today? If both dates include the same day, the engine still finds two candidates. One day’s difference makes the resolution deterministic.

Worked Example

Item purchased from Vendor A, USD, quantity break of 1:

After posting: any PO dated 24 June or later picks $6.50. Historical POs on or before 22 June still resolve to $7.00. Clean, unambiguous, audit safe.

Where to Enforce This Rule

Inbound integration: If prices flow from a legacy system via OData, build a custom API endpoint in D365 FO that handles closure server-side. For each incoming line, the API finds the active record, generates a closing line (To Date = Today − 1), creates the new line (From Date = Today), and posts the journal atomically. This avoids the three round trips and race conditions of handling closure on the source side.

Manual entry by buyers: Add an event handler on the Trade Agreement Journal line table that auto-generates a paired closing line whenever a buyer adds a new price. The buyer reviews both lines in the unposted journal and posts as usual. This removes the human step that’s been failing, while still giving the buyer visibility and control before committing.

Edge Cases to Handle

1. No prior record exists – skip the closure, just create the new record.
2. Multiple overlapping records exist – close all of them (bad data cleanup) and log a warning.
3. From Date is in the past or future -set the old record’s To Date to (new From Date − 1) instead of (Today − 1).
4. Identical price (same key, same amount) – treat as a no-op to avoid duplicates.

To conclude, everything in this article comes down to one rule: never leave the old price open when you create a new one. Close it with a To Date of one day before the new price starts. Do it in the same journal, in the same transaction, whether the price comes from an integration or a buyer’s keyboard.

Here’s your next step: run a query on your PriceDiscTable for any Item × Vendor combinations that have more than one active PricePurch record with overlapping date windows. The results will tell you the scale of the problem. If you find dozens or hundreds, it’s time to automate the closure rule.

At CloudFronts, we’ve built this pattern into multiple D365 F&O procurement implementations. If you need help diagnosing your trade agreement data or building the closure automation into your integration and manual entry workflows, reach out to us. Let’s make sure your system gives your buyers the right price, every time.

Ready to modernize your finance and supply chain operations with Dynamics 365 Finance & Operations?
CloudFronts delivers intelligent automation, seamless integrations, and process optimization solutions that help you maximize the value of your ERP investment. Reach out at transform@cloudfronts.com