What are price attributes, component codes and price…

What are price attributes, component codes and price structures?

Tier: Finance & Operations. Four objects, four names that sound interchangeable and are not, and one of them silently decides who in your business can maintain pricing at all.

Start with the arithmetic, because it is published

From the Unified pricing management module overview [GA] (ms.date 2026-04-20, updated_at 2026-04-21):

"The base price is the price before any price adjustments are made (Base price + Price adjustment = Selling price)."

Everything below exists to determine two numbers on the left of that equation. The module is not a price list; it is a calculation graph, and the four objects are its parts.

The four objects, in Microsoft's words

Price attributes — "Price attributes give you a flexible way to define your pricing factors. They use information about customers, products, sales order headers, and sales order lines."
Price component codes — "Price component codes group together price attributes. They represent the building blocks of your price structure. When you create a price and discount rule record, you also assign that record to a price component code."
Price structures — "Price structures help you understand the sequence of your price component codes."
Concurrency modes — "Concurrency modes control how the final price is calculated in situations where multiple pricing rules are associated with the same price component code."

Read them as a hierarchy and the vocabulary stops being slippery. Attributes are the facts. Component codes are the buckets those facts sit in — and every pricing and discount rule you write is assigned to one. A price structure is the order the buckets are evaluated in. Concurrency modes settle fights inside one bucket, which is chapter 5.

The Price component codes page (ms.date 2026-05-18, updated_at 2026-07-01) opens with the design intent stated more plainly than most vendor documentation manages:

"The goal of making pricing decisions is to increase profitability. Good decision making requires a thorough understanding of the different elements that determine the price."

It also names what a price component code can carry: "Price component codes can define default values for posting and the discount concurrency mode." Your default concurrency behaviour lives on the bucket, and individual rules override it — which is why a change at code level moves prices in places nobody was looking.

The rule most people meet the hard way

There is a hard cardinality constraint, and it is a Note rather than a heading:

"You can have a maximum of one price component code record for each of the following price components: Base price - inventory price / Base price - purchase price / Base price - sales price / Sales trade agreement. You can have any number of price component code records for each of the remaining price components."

One sales base price component. One trade agreement component. Unlimited discount and margin components. So a design that wants two parallel base-price regimes — say one per business unit inside a legal entity — cannot be expressed at that layer. The variation has to move into attributes and rules beneath the single component, or into separate price structures. Finding that out during a build is expensive; it is one Note on one page.

Maintenance mode decides who owns pricing

When you create a price component code you choose a Maintenance mode, and the page is explicit that this is permanent: "You can edit this field only for new records. (It becomes read-only when you save the record.)"

"Separate – You can assign a rank to each individual header and line attribute group. The system then automatically generates each possible combination of header and line attribute groups, and assigns a combined rank to each combination, based on your individual rankings."

"Combined – You can define each relevant combination of header and line attributes, and manually assign a combination rank to each of them."

This is the real fork. Separate generates the combination matrix for you from two ranked lists — fast to set up, and it produces rows nobody explicitly asked for. Combined makes you write every combination and rank it by hand — slower, fully deliberate, and it scales badly.

Choose Separate and pricing maintenance is a task a merchandiser can do. Choose Combined and it becomes a task somebody has to be trained for. That is an operating-model decision wearing the clothes of a configuration field, and it is read-only after save.

How a tie between two reasonable rules is broken

Microsoft states the problem honestly:

"In general, specific pricing rules (that is, rules that apply to a specific customer account and product number) take priority over more general rules … However, if two equally general rules apply (for example, a rule that targets a specific customer group and a rule that targets a specific region), it can be difficult to determine which rule should have priority."

The answer is combination rank, and it applies only under two conditions, both quoted:

"- Multiple pricing rules in the same price component code apply to the same order line. - For all the qualifying rules, the Concurrency mode field is set to Price attribute combination rank."

Then "the rule that matches the row with the highest Combination rank value applies." Microsoft's own worked example ranks a customer-group-and-product-group combination at 2002 and a market-segment-and-category combination at 1001, and selects the first — "Therefore, the price is $20."

Rank is not priority. It is a number generated from two independent rankings you set, and it only decides anything when every competing rule is in that mode.

What the structure does not contain

Walk the four objects again as a list of inputs: customer facts, product facts, order header facts, order line facts, the order they are evaluated in, and the rule for resolving collisions.

Nothing in the four definitions above is an input about outcomes — not what the customer accepted last quarter, not what the order would have converted at, not what this line costs you today. The structure is a complete and precise description of how your rules combine. It is silent on whether they are the right rules, and it is designed to be: Microsoft's own framing is that good decision making requires understanding the elements, and the module supplies the elements.

How we build it: rules into the structure, never a second structure

Pricing & Discount Optimizer decides which pricing and discount rules earn the most margin across the book, re-plans them as demand and cost move, and writes them back as records against your existing price component codes — behind an approval step. Into your structure, at your ranks, under your concurrency modes. An optimizer that needed its own price structure would be a second pricing engine, and you already have a capable one.

A working demo exists; it is not off the shelf. We build it against your systems and your constraints on request, and we have no delivered pricing engagements — so this is a capability, not a report on somebody's business. We do not touch your ERP core, and the structure stays your implementation partner's.

Three things to check this week

Open each price component code and note its Maintenance mode. It is read-only, it was chosen once, and it determines whether pricing maintenance is a merchandising job or an IT one.
Read the default discount concurrency mode on every discount component code. Rules inherit it unless overridden, so this is the setting with the widest blast radius in the module.
Count your price structures. If there is one per company and your commercial reality has more than one pricing regime, the single-base-price constraint above is already shaping your rules.

Chapter 5 is what happens when two rules land in the same bucket. Chapter 6 is how to tell whether you are on this module at all.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Runs Finance & Operations and want to know what your price structure is actually deciding? Book a 15-minute call — we'll walk the decision and the model with you, on your data if you bring it. No deck.

What are price attributes, component codes and price structures?