Visa CEDP requirements center on one principle: real transaction data, properly formatted, submitted consistently.
Key Takeaways:
- Required fields: Purchase Identifier, Sales Tax, Postal Code, Country Code, Order Date
- Product 3 adds: Item Description, Quantity, Unit Price, Commodity Code per line item
- 90% data quality threshold required to maintain Verified status
- Format matters: YYMMDD dates, no currency symbols, ISO country codes
- Fake/randomized data gets flagged by Visa's AI validation
Meeting these requirements earns you Verified merchant status and access to Product 3 interchange rates. Failing them costs you money on every B2B transaction. There is no middle ground.
The Commercial Enhanced Data Program replaced the legacy Level 2 and Level 3 qualification system in April 2025. The data elements are similar, but Visa now audits them with AI-powered validation. Placeholder values that passed five years ago trigger automatic downgrades today.
Core Data Requirements
Every CEDP-qualifying transaction must include these fields. Missing or incorrectly formatted data fails the audit.
Transaction-Level Fields (Required for All)
| Field | Format | Example | Common Failure |
|---|---|---|---|
| Purchase Identifier | Alphanumeric, up to 25 chars | PO-2026-00147 | Using "N/A" or blank |
| Sales Tax Amount | Decimal with 2 places | 847.50 | Omitting when tax-exempt |
| Destination Postal Code | 5 or 9 digit US format | 90210 or 90210-1234 | International format mismatch |
| Destination Country Code | ISO 3166-1 alpha-2 | US | Using full country name |
| Order Date | YYMMDD format | 260106 | Different date formats |
The Purchase Identifier trips up most merchants. According to Visa's merchant regulations, this field must contain a legitimate business reference, typically a customer PO number or internal order ID. Values like "00000," "NOPO," or repeated characters fail validation.
Sales Tax Amount requires special attention for tax-exempt transactions. You must submit $0.00 explicitly, not leave the field blank. Visa's system interprets missing values as data quality failures.
Line Item Detail (Required for Product 3)
Product 3 (formerly Level 3) qualification demands line-item specifics. Each item in the transaction needs:
| Field | Format | Example | Notes |
|---|---|---|---|
| Item Description | Alphanumeric, 35 chars max | Industrial valve 2-inch | Meaningful description required |
| Quantity | Numeric with decimals | 12.00 | Cannot be zero |
| Unit of Measure | Industry standard codes | EA, DZ, CS, GAL | Must match item type |
| Unit Price | Decimal with 4 places | 125.7500 | Pre-tax price per unit |
| Extended Amount | Decimal with 2 places | 1509.00 | Quantity x Unit Price |
| Item Commodity Code | UNSPSC or custom | 40141700 | Valid code required |
The Item Commodity Code catches many merchants off guard. Visa accepts UNSPSC (United Nations Standard Products and Services Code) or your industry's equivalent. Making up codes or using placeholder values triggers immediate rejection.
The 90% Quality Threshold
Visa measures data quality monthly across all your CEDP-participating transactions. You need 90% compliance to maintain Verified status.
This threshold applies to individual fields, not just overall transactions. If your Purchase Identifier passes 95% of the time but your Item Commodity Code only passes 85%, your aggregate score suffers.
| Compliance Rate | Status | Rate Impact |
|---|---|---|
| 90%+ consistent | Verified | Immediate Product 3 rates |
| Below 90% | Non-Verified | Standard rates, lagged review |
| Persistent failure | Status loss | Full interchange penalty |
The review cycle runs monthly. Visa's acquirer reports show exactly which fields fail and how often. If you're not reviewing these reports, you're flying blind.
Format Specifications That Matter
Correct data in the wrong format fails. Visa's validation is strict.
Dates: YYMMDD only. Not MMDDYY, not YYYY-MM-DD, not spelled out. January 6, 2026 becomes 260106.
Currency: No symbols. No commas. Two decimal places for amounts, four for unit prices. $1,500.00 becomes 1500.00.
Text fields: No special characters in descriptions. Alphanumeric plus spaces only. Ampersands, quotes, and slashes cause parsing failures.
Postal codes: US domestic uses 5 or 9 digits (with hyphen for 9). International follows the destination country's format, paired with the correct ISO country code.
These seem minor until a batch of 500 transactions fails because your ERP exports dates in the wrong format. We've seen it happen.
The Problem With Fake Data Solutions
Some processors pitch systems that "auto-populate" CEDP fields. The sales story sounds good: no ERP integration required, instant compliance, keep your current rates.
What they're actually doing is generating synthetic data that mimics real values. Purchase Identifiers get random alphanumeric strings. Line item details pull from generic product databases. Tax amounts get calculated from averages.
This worked briefly. Then Visa's AI audits got smarter.
The pattern recognition in Visa's validation system identifies machine-generated data by its statistical signatures. Random strings have tells. Generic descriptions repeat across merchants. Tax calculations that never vary by product category raise flags.
We firmly believe the only sustainable path forward is authentic data. Your actual PO numbers. Your real product descriptions. Your genuine tax amounts from the transaction.
Relying on a machine to generate fake numbers might work today. It puts your business at massive risk tomorrow. When Visa's machine-driven audits catch machine-generated data (and they will), program abuse penalties apply. Those penalties make the interchange savings look trivial.
ERP Integration Requirements
Your ERP system holds most of the data Visa requires. The challenge is getting it to your payment gateway in the right format.
What Your ERP Must Export
- Customer PO number (from sales order)
- Ship-to address with postal code
- Sales tax by line item
- Product descriptions (not just SKUs)
- Unit of measure codes
- Commodity codes (or a mapping table)
What Your Gateway Must Accept
- Extended transaction records (not just auth and capture)
- Line item arrays with variable length
- Field-specific formatting as described above
Common Integration Gaps
- SAP: Standard iDocs don't include all CEDP fields. Custom enhancement required.
- NetSuite: SuiteScript can export the data, but gateway compatibility varies.
- Oracle: Requires middleware for most payment gateways.
- QuickBooks: Limited native support. Third-party solutions needed.
The integration work is real. Budget $15,000-75,000 depending on your stack complexity. But compare this to the monthly cost of non-compliance at scale.
Fleet and EV Charging Requirements
Visa added specific fields for fuel and electric vehicle transactions.
Fleet Fuel Transactions
| Field | Required | Notes |
|---|---|---|
| Fuel Type | Yes | Diesel, unleaded, etc. |
| Fuel Quantity | Yes | Gallons with decimals |
| Unit Price per Gallon | Yes | 4 decimal places |
| Odometer Reading | Yes | Vehicle mileage at fill |
| Non-Fuel Product Code | Conditional | Required for mixed purchases |
Single fuel-only Fleet transactions are excluded from CEDP. Mixed purchases (fuel plus convenience store items) require full line-item detail.
EV Charging Transactions (MCC 5552)
| Field | Required | Format |
|---|---|---|
| Expanded Fuel Type | Yes | EV charging indicator |
| Connector Type | Yes | CHAdeMO, CCS, Tesla, etc. |
| Charging Power Output | Yes | kW capacity |
| Start Time | Yes | HHMMSS |
| End Time | Yes | HHMMSS |
| Total Charging Time | Yes | Minutes |
| Plugged-In Duration | Yes | Minutes |
EV charging requirements took effect October 2025. If you operate charging stations, your point-of-sale system must capture these metrics.
Validation Testing Before Go-Live
Don't assume your integration works. Test it.
-
Submit test transactions. Use real data, not production volume. Verify each field populates correctly.
-
Request acquirer reports. Within 30 days, you'll see which fields pass and which fail.
-
Fix before scaling. One bad field across thousands of transactions creates a cleanup nightmare.
-
Monitor monthly. Data quality drifts. Staff changes, ERP updates, and gateway upgrades all introduce risk.
Checklist for CEDP Compliance
Use this list to audit your current state:
Transaction-Level Data
- Purchase Identifier populated with real PO/order number
- Sales Tax Amount included (or $0.00 for exempt)
- Destination Postal Code in correct format
- Destination Country Code as ISO alpha-2
- Order Date in YYMMDD format
Line Item Data (Product 3)
- Item Description meaningful and 35 chars or less
- Quantity populated and non-zero
- Unit of Measure using standard codes
- Unit Price with 4 decimal places
- Extended Amount calculated correctly
- Item Commodity Code valid
System Integration
- ERP exports all required fields
- Gateway accepts extended transaction format
- Formatting matches Visa specifications
- No placeholder or dummy values in production
Monitoring
- Monthly acquirer report reviewed
- Field-level pass rates tracked
- 90% threshold maintained
Frequently Asked Questions
What data fields are required for CEDP? Every CEDP transaction requires: Purchase Identifier (real PO number), Sales Tax Amount ($0.00 if exempt), Destination Postal Code (5 or 9 digits), Country Code (ISO alpha-2 like "US"), and Order Date (YYMMDD format). Product 3 adds line-item fields: description, quantity, unit of measure, unit price, extended amount, and commodity code.
What is the CEDP compliance threshold? You need 90% data quality across all fields to maintain Verified status. Visa measures this monthly. If your Purchase Identifier passes 95% but your Commodity Code only passes 85%, your aggregate score drops and you risk losing Verified status.
What date format does CEDP require? YYMMDD only. January 6, 2026 must be submitted as 260106. Not MMDDYY, not YYYY-MM-DD, not spelled out. Wrong date formats are one of the most common CEDP failures we see.
Does CEDP accept placeholder or dummy data? No. Visa's AI validation specifically identifies placeholder values like "N/A," "00000," or machine-generated random strings. Using fake data can result in program abuse penalties beyond just losing Verified status.
