Order does not matter, but two sections are required

A plan document may present its sections in any order. Two of them are required: the rules that decide who gets credit, and the currency rates the plan is denominated in. Everything else is optional, because plans legitimately vary — not every plan has territories, and not every plan pays on products.

Participants — who gets paid

A participant is a person the plan pays. The section's central idea is that one person has many identities: an ID in the CRM, another in the HR system, another in payroll. The standard lets a participant carry all of them, because reconciling those identities by hand is where commission data most often goes wrong.

Participants also carry their relationships to other participants, which is what makes manager rollup and overlay credit expressible; their roles over time; and their target variable — the at-risk portion of compensation the plan is designed to pay out.

Roles and Components — what the plan pays for

A role is a job the plan compensates, and its components are the plan's actual structure. Each component describes one thing a participant is paid for, how heavily it is weighted against the others, and how attainment against it becomes money.

Components deliberately separate how often attainment is measured from how often it is paid. These are different questions and conflating them is a common source of disputes: a plan can measure attainment quarterly while paying monthly against it, and the participant's understanding of their own plan depends on that distinction being explicit.

Rate Tables — how attainment becomes money

A rate table turns a level of attainment into a rate. Tables are tiered, each tier carrying a multiplier that applies once that threshold is reached.

Tiers may be marked retroactive, which is the part most worth stating precisely. A retroactive tier reaches backward through preceding retroactive tiers and applies its multiplier to them as well, stopping at the first tier not marked retroactive. The difference between a retroactive and non-retroactive accelerator is often a large amount of money, and it is frequently ambiguous in prose plan documents.

Regions and Products — the dimensions

Regions and products are the dimensions the rest of the plan refers to: the territories a plan is scoped to, and the product lines it pays differently on. They exist as their own sections so that a rule or a quota can point at them rather than restating them.

Rules — who gets credit

Rules answer the crediting question: given a transaction, which participants are credited for it, and for how much. Each rule names the data it draws on and the conditions that must hold.

Crediting is where plan documents are usually vaguest and where disputes concentrate. Expressing it as explicit conditions is the point — a rule that cannot be written down unambiguously is a rule that will be applied inconsistently.

Currencies — required, and here is why

Currency rates are one of the two required sections, which surprises people running single-currency plans. The reason is reconstruction: a plan that cannot state the rate it was paid at cannot be re-derived later. A payment made last March depends on last March's rate, and a plan definition that omits it can be recomputed only by accident.

Everything is effective-dated

Effective dates hang off nearly every part of the standard — participants, roles, components, rate tiers, currency rates. This is the schema's central design claim: a compensation plan is not a snapshot, it is a history. Plans are amended mid-year, people change roles mid-quarter, and rates move daily. A format that records only the current state cannot answer what a plan said when a disputed payment was made.

Hierarchies are flat, on purpose

Participant identifiers, regions, and products all share one shape: a node with an identifier, a name, and an optional pointer to its parent. Trees are expressed as flat nodes with parent references rather than by nesting elements inside one another.

This is a deliberate trade. Nested elements read more naturally, but they are considerably harder to validate and query, and the standard favours being checkable over being pretty.

Not yet in version 1

Some things are visibly unfinished, and it is better to say so than to let an evaluator discover them by reading the schema. A standalone commission plan section is defined but not yet part of a plan document. A top-level quota section is not included either; quotas presently attach to participants and roles directly. Rate tier modifiers do not yet express what a threshold is measured against — an absolute amount, or a percentage of some other value. And while a custom payout frequency can be named, the standard does not yet say how a custom frequency is described.

These are open questions rather than oversights, and they are the most useful places to push if you want to shape the next version.