Premier PCR File Controlled Vocabulary: A Step-by-Step Build Guide

What is the Premier PCR file controlled vocabulary?

Premier's PCR (Price Change Request) file is the structured submission format Premier Inc. requires for contract pricing updates, and the controlled vocabulary is the fixed set of allowed values for each column — Action Code, UOM, Contract ID, Effective Date format. Free-text entries, deprecated codes, or wrong casing cause automatic file-level rejection before any human reviewer sees the row.

Suppliers who have worked Vizient's PPA cross-reference process or HealthTrust's PMM submissions sometimes assume Premier's PCR structure follows the same logic. It does not. Vizient's format leans on tracings and admin fee columns that don't exist in a Premier PCR file, and HealthTrust enforces its own unit-of-measure abbreviations. A file built for one GPO's controlled vocabulary will not pass another's validation untouched, even when the underlying pricing data is identical. Treat each GPO's vocabulary as a separate contract with your submission process, not a variation on a shared template. This distinction matters most when a contract analyst is juggling all three portals in the same renewal cycle and reaches for whatever mapping table was open last.

Where Premier publishes the current field and value list

Premier does not publish its controlled vocabulary inside the RFP PDF. The current field and value list lives inside the supplier portal, attached to the specific contract's documentation folder, and it changes with each contract cycle rather than on a fixed calendar.

Pull the vocabulary export fresh at the start of every PCR cycle. A contract that renewed or restructured tiers since your last submission may have added, retired, or renamed accepted values, and reusing last year's saved copy is the single most common cause of a full-file rejection. Premier's supplier resources page is the entry point for locating the correct contract documentation folder, and from there the portal generates a downloadable template.

Two practitioner details matter here. First, Premier expects a specific file naming convention — contract number, revision number, and date stamp — and a mismatched name can trigger a portal-level rejection before the data itself is even parsed. Second, the exported template arrives as an .xlsx file with a hidden "data validation" tab. That tab, not the visible column headers, contains the actual dropdown-enforced value list Premier's system checks against. Skipping it is why files that "look right" still fail.

Step 1-4: Mapping your ERP export to Premier's controlled fields

Mapping an ERP export to Premier's PCR structure is a four-step sequence: extract raw pricing data, cross-reference every internal code against Premier's controlled list, convert casing and abbreviations to the exact accepted string, then lock the file so no manual override can slip back in before export.

1. Extract: Pull raw pricing rows straight from the ERP or CRM system — item number, UOM, member ID, effective date — without touching values manually at the source. Manual edits at this stage are the hardest to trace later.
2. Cross-reference: Check every internal code, not your own catalog's vocabulary, against Premier's controlled list from the hidden validation tab. Internal shorthand rarely matches Premier's accepted strings one-to-one.
3. Convert: Standardize casing and unit-of-measure abbreviations to the exact string Premier accepts — "CS" instead of "BX," "Each" instead of "EA" if that's what the current vocabulary tab specifies. GS1 US publishes broader unit-of-measure conventions that many ERP systems default to, but Premier's accepted strings can diverge from those defaults, so verify against the portal export directly.
4. Lock: Apply cell-level formulas or data validation rules so no free-text override can bypass the mapped value before the file leaves your hands. This step catches the analyst who "just fixes one row quickly" before upload.

Controlled vocabulary field reference table

The table below covers the six PCR fields most responsible for rejections: what Premier's controlled vocabulary accepts, why suppliers get it wrong, and the specific fix. Use it as a pre-submission reference alongside the portal's hidden validation tab, not as a replacement for pulling the current export.

Worked example: fixing a 1,240-line PCR file that Premier rejected

A supplier submitted a 1,240-line PCR file to Premier and received 87 rejected rows, all flagged for UOM and Action Code mismatches. Remapping the file against the current controlled vocabulary and resubmitting dropped the rejected rows to 3, cutting turnaround from 11 business days to 2.

The root cause traced back to a single ERP export setting: the system defaulted case-unit rows to "BX," while Premier's current contract cycle had standardized on "CS" for the same unit. Because the mismatch sat inside a controlled field rather than a free-text one, Premier's portal rejected every affected row rather than flagging it for manual review. The supplier's team had visually checked the file and it "looked correct," which is exactly the trap — visual review catches typos, not vocabulary drift between contract cycles.

Two rejection-and-resubmission cycles had already burned 11 business days before the team traced the issue to the UOM field specifically. Applying a static lookup table — one column mapping every internal UOM code to Premier's current accepted string — brought the rejected count down to 3 on the very next submission, and those 3 were legitimate No-Cross situations requiring a different flag, not another mapping error. Turnaround on the corrected file dropped to 2 business days because the file passed initial portal validation on the first pass.

The PCR Vocabulary Lock (PVL) Method

The PCR Vocabulary Lock, or PVL Method, is a four-stage framework for building Premier-compliant files: Extract, Map, Validate, Submit. Each stage exists to remove a specific point where manual typing or stale data reintroduces a vocabulary mismatch after the file has already been checked once.

Extract means pulling raw data from the source system with zero manual edits — no "quick fix" typed directly into the export before it moves to mapping. Map means applying a static lookup table that ties every internal code to Premier's current controlled string, built once per contract cycle and stored as a reference file rather than retyped each submission. Validate means running the mapped file against the portal's hidden data-validation tab before upload, catching mismatches locally instead of discovering them through a rejection notice days later. Submit means locking the file name and revision number to match Premier's naming convention exactly, then archiving both the submitted file and its mapping table so the next contract cycle starts from a known-good baseline instead of guesswork.

The value of the PVL Method is procedural, not technical. Every stage assumes the previous stage's output is trustworthy, which means no stage allows a manual override to slip back into a field that's already been mapped or validated. Contract teams that skip the Validate stage — assuming the Map stage was enough — are the ones who discover UOM drift only after Premier's rejection notice arrives, days later than a local check would have caught it.

Edge cases that generic PCR guides miss

Four edge cases account for a disproportionate share of Premier PCR rejections that generic submission guides don't cover: trailing whitespace, merged facility handling, multi-UOM rows, and fiscal-year date drift. Each one passes a casual visual check while still failing the portal's automated parser.

• Trailing whitespace: A Member ID column with a trailing space after the code looks identical to the correct value on screen but fails exact-match validation in the portal. Strip whitespace programmatically before export; don't rely on eyeballing the cell.
• Merged or renamed facilities: When member facilities merge or rename mid-contract, the correct handling is a No-Cross flag on that row, not a blank row or a guessed member ID. A blank row often causes a full-file rejection rather than a single-row skip.
• Multi-UOM items: Items sold in both each and box units need separate PCR lines for each UOM. A single row with a slash-separated value ("EA/BX") is not a controlled vocabulary entry and will reject.
• Fiscal-year date drift: Effective dates near a fiscal-year boundary can silently default to the wrong contract year if the date format drifts from Premier's expected string, since a misformatted date can parse as valid but land in the wrong cycle without triggering an obvious error.

Pre-submission QA checklist before uploading to the portal

A pre-submission checklist catches what automated validation sometimes misses: stale vocabulary references, naming mismatches, and recurring ERP bugs that resurface across contract cycles. Run this sequence before every upload, not just after a prior rejection.

1. Run a column-by-column diff against the vocabulary export pulled at the start of the current cycle — never a saved copy from a previous submission.
2. Spot-check at least 10 random rows manually even after the automated validation pass shows clean, since automated checks confirm format compliance but not business-logic correctness like tier assignment.
3. Confirm the file name and revision number match the portal's expected naming convention exactly, including date stamp formatting.
4. Maintain a rejection log noting which specific field caused each historical rejection, so recurring ERP export bugs — like the BX/CS UOM mismatch in the worked example above — get fixed at the source instead of re-patched every cycle.

How Premier's vocabulary rules differ from Vizient and HealthTrust

Premier's PCR structure, Vizient's PPA process, and HealthTrust's PMM format each enforce a different controlled vocabulary, which means a single ERP export cannot serve all three GPOs unmodified. Suppliers holding multi-GPO contracts need separate mapping tables per GPO, not one shared lookup applied across portals.

Vizient's cross-reference process centers on tracings and admin fee columns that have no equivalent field in Premier's PCR structure, since Premier's format is built around price change actions rather than tracing-based cross-referencing. Vizient's supplier portal documents these process differences directly. HealthTrust, meanwhile, enforces its own UOM abbreviation set through its supplier resources, and that set doesn't always align with either Premier's or Vizient's accepted strings for the same physical unit.

The common failure mode: a contract analyst validates a UOM string against Vizient's rules, confirms it passes, then reuses that same value directly in a Premier PCR file without remapping. It passes visual review because it's a valid-looking abbreviation — just not the one Premier's current contract cycle accepts. Keeping separate, cycle-current mapping tables per GPO, reviewed at each contract renewal through resources like GPO contract operations guidance, avoids this specific cross-contamination between portals.

FAQ: Premier PCR file controlled vocabulary

Where do I download Premier's current PCR controlled vocabulary list?

Log into the Premier supplier portal, open the active contract's documentation folder, and export the .xlsx template. The hidden validation tab inside that file lists every dropdown-enforced value; do not reuse a prior contract cycle's copy, since values shift with contract renewals and tier restructuring.

Why does my PCR file still fail validation after matching the value list?

Trailing spaces, wrong casing, or Excel auto-formatting — like dates converting to serial numbers — commonly cause failures even when values look correct visually. Re-export as plain text, strip whitespace programmatically, and lock cell formats as text before uploading rather than trusting a visual scan.

Can I submit a PCR file with partial vocabulary compliance?

No. Premier's portal validates the entire file against the controlled vocabulary before accepting any rows, so a single non-compliant field can reject the full submission rather than isolating and skipping just the offending line. Every row in the file needs to pass before any row is processed.

How often does Premier update its controlled PCR values?

Values can change at each contract renewal or tier restructuring, not on a fixed annual schedule. Pull a fresh vocabulary export at the start of every new PCR cycle instead of assuming last cycle's mapping table still applies, since even a mid-cycle tier change can alter accepted member tier codes.

What is the difference between a PCR rejection and a No-Cross flag?

A rejection means the file itself failed format or vocabulary validation and nothing in it was processed by Premier's system. A No-Cross flag is a valid submission indicating a specific item or member cannot be cross-referenced to the contract, and that row still needs to be fully controlled-vocabulary-compliant to be accepted as a legitimate No-Cross entry.