Audience: EDI developers, B2B integration teams, ERP administrators

Your EDI transactions are failing with "Element is mandatory" errors related to product identification fields. This happens when required UPC codes, SKU numbers, or product ID qualifiers are missing from 850 purchase orders, 810 invoices, 846 inventory updates, or 880 grocery transactions.

What These Errors Mean

EDI transactions use product identification fields to tell your trading partner exactly which items you're ordering, invoicing, or updating inventory for. When these fields are empty or missing, the transaction fails validation because your trading partner's system can't process line items without knowing what product is being referenced.

Most trading partners require at least one product identifier per line item. Some partners require multiple mandatory product references per line item, for example, both a UPC and a SKU on every line. Check your trading partner's guidelines in Orderful to confirm what's required.

What the Transaction Looks Like for This Error

Unlike other errors that prevent a transaction from being created, this is a validation error. The transaction is created in Orderful, but its validation status is Invalid.

To find the error:

Open the transaction in Orderful
Go to the Rules Editor tab
You will see errors on the specific JSON paths that failed validation — each error is tied to the exact path of the missing field

How to Diagnose Which Fields Are Missing

Step 1: Read the error path

Each error in the Rules Editor will reference the exact JSON path of the missing field. For example:

transactionSets.0.PO1_loop.0.baselineItemData.0.productServiceID — missing product ID in an 850 purchase order
transactionSets.0.PO1_loop.0.baselineItemData.0.productServiceIDQualifier — missing qualifier in an 850 purchase order
transactionSets.0.IT1_loop.3.baselineItemDataInvoice.0.productServiceID — missing product ID in an 810 invoice
transactionSets.0.G17_loop.14.itemDetail.0.number — missing G1704 number in an 880 grocery order

If the error path isn't immediately clear, the table at the end of this article lists the most common paths by transaction type.

Step 2: Understand the productServiceID and productServiceIDQualifier pair

In most cases. productServiceID values don't mean anything on their own, they are paired with productServiceIDQualifier, which tells the system what type of reference the ID is. For example:

productServiceIDQualifier = SK → the value in productServiceID is a SKU number
productServiceIDQualifier = UP → the value in productServiceID is a UPC code (12 digits)

Both fields must be present together. If either is missing, the transaction will be Invalid.

Step 3: Check for multiple mandatory references

If your trading partner requires multiple product references per line item, they will each have their own numbered path:

productServiceID, productServiceID1, productServiceID2, ...
productServiceIDQualifier, productServiceIDQualifier1, productServiceIDQualifier2, ...

Check the error paths carefully — there may be more than one pair required.

How to Diagnose Where the Missing Value Is

Once you know which field is missing, determine where the problem lies:

The value is in the source system but not in the transaction — your integration or connector isn't pulling it through. Update your integration to include the missing field, or contact your connector or integration owner to add it.
The value is in the transaction but not in the expected path — the data exists but is mapped to the wrong field (e.g., the required value is in productServiceID2 but the partner expects it in productServiceID). This can be fixed with a SET or LOOKUPV2 rule in Orderful without touching the source system or integration.
The value is in a related transaction — your integration provides the primary product service IDs, but the partner requires additional identifiers (e.g., productServiceID1, productServiceID2) that your system doesn't send. If those additional identifiers aren't stored in your source system and were already transmitted on a related transaction — for example, the original 850 purchase order — you can use a TURNAROUND rule in Orderful to retrieve the matching values from the 850 and populate the missing fields on the return transaction (e.g., an 810 invoice or 856 ASN). No changes to your source system or integration are needed.
The value is nowhere — it doesn't exist in your source system (SOR) and is not in the transaction or related transaction. You'll need to add it to your source system.

Fix 1: Missing Product Service ID (850, 855, 856, 810, 846)

If the value is nowhere — update your source system: Add the missing product identifier (UPC, SKU, vendor part number, etc.) to your ERP, inventory management system, or source of record. Once it's available in the source system, update your integration to pull it through and resend the transaction.
If the value is in the source system but not in the transaction — update the integration: Contact your integration or connector owner to include the missing field in the transaction payload. Once the integration is updated, resend the transaction.
If the value is in the transaction but not in the expected path — write a rule in Orderful: You don't need to change your source system or integration. Instead, write a rule in the Rules Editor to move or copy the value to the correct path. No resend is needed — the rule will apply automatically to future transactions.
- If the value is within the same segment (e.g., the required productServiceID is actually arriving in productServiceID2), use a SET rule.
  Example:
```
SET($transactionSets.*.PO1_loop.*.PO1.*.PO109)
```
- If the value is outside the current segment (e.g., in a different loop or a custom field), use a LOOKUPV2 rule to retrieve it from elsewhere in the payload and write it to the correct path.
  Example:
```
LOOKUPV2($transactionSets.*.PO1_loop.*.PID_loop.*.PID, "S", $transactionSets.*.PO1_loop.*.PID_loop.*.PID.*.PID01, $transactionSets.*.PO1_loop.*.PID_loop.*.PID.*.PID05)
```

Fix 2: Missing Product Service ID Qualifier (850, 855, 856, 810, 846)

For a given trading partner, the qualifier is almost always the same for every transaction — if you're sending UPCs, the qualifier is always UP; if you're sending SKUs, it's always SK. This means the qualifier can typically be hard-coded with a SET rule rather than requiring a change to your source system or integration.

Example: Hard-code the qualifier as SK for every line item:

SET ("SK")

This rule will apply automatically to all future transactions for this partner. No resend is needed once the rule is in place.

Fix 3: Missing Product Service ID — Grocery Transactions (875, 880)

Grocery transaction types (875 and 880) are stricter about UPC identification and use dedicated paths rather than the standard productServiceID / productServiceIDQualifier pair.

For the primary UPC on each line item, use the dedicated grocery paths:

880: itemDetail.0.number (the G1704 field)
875: itemDetail.0.number (the G6804 field)

These fields are specifically for UPC codes and do not use a qualifier — the UPC goes directly into the number field.

For additional product references on the same line item (e.g., a vendor part number or internal item ID in addition to the UPC), grocery transactions also support the standard paired paths:

productServiceIDQualifier + productServiceID

If your error path references itemDetail.0.number, the grocery retailer's internal item ID or UPC is missing from that dedicated field. Get the correct item IDs from your trading partner — grocery retailers often use their own internal item numbering system — and ensure your integration populates the correct path.

Common Product Service ID Paths by Transaction Type

Transaction Type	Field	X12 Element	JSON Path	Paired Qualifier Path	Paired Qualifier X12 Element
850	Primary Product service ID	PO107	`PO1_loop.*.baselineItemData.0.productServiceID`	`...baselineItemData.0.productServiceIDQualifier`	PO106
850	Additional Product service IDs	PO109, PO111...	`...baselineItemData.0.productServiceID1`, `productServiceID2`...	`...productServiceIDQualifier1`, `productServiceIDQualifier2`...	PO108, PO110...
810	Primary Product service ID	IT107	`IT1_loop.*.baselineItemDataInvoice.0.productServiceID`	`...baselineItemDataInvoice.0.productServiceIDQualifier`	IT106
810	Additional Product service IDs	IT109, IT111...	`...baselineItemDataInvoice.0.productServiceID1`, `productServiceID2`...	`...productServiceIDQualifier1`, `productServiceIDQualifier2`...	IT108, IT110...
856	Primary Product service ID	LIN03	`HL_loop.*.SN1_loop.0.itemIdentification.0.productServiceID`	`...itemIdentification.0.productServiceIDQualifier`	LIN02
856	Additional Product service IDs	LIN05, LIN07...	`...itemIdentification.0.productServiceID1`, `productServiceID2`...	`...productServiceIDQualifier1`, `productServiceIDQualifier2`...	LIN04, LIN06...
846	Primary Product service ID	LIN03	`LIN_loop.*.itemIdentification.0.productServiceID`	`...itemIdentification.0.productServiceIDQualifier`	LIN02
846	Additional Product service IDs	LIN05, LIN07...	`...itemIdentification.0.productServiceID1`, `productServiceID2`...	`...productServiceIDQualifier1`, `productServiceIDQualifier2`...	LIN04, LIN06...
880	Primary UPC	G1704	`G17_loop.*.itemDetail.0.number`	(no qualifier — UPC goes directly in this field)	—
880	Additional Product service IDs	G1706, G1708...	`G17_loop.*.itemDetail.0.productServiceID`	`...itemDetail.0.productServiceIDQualifier`	G1705, G1707...
875	Primary UPC	G6804	`G68_loop.0.itemDetail.0.number`	(no qualifier — UPC goes directly in this field)	—
875	Additional Product service IDs	G6806, G6808...	`G68_loop.0.itemDetail.0.productServiceID`	`...itemDetail.0.productServiceIDQualifier`	G6805, G6807...

Common Product Service ID Qualifier Codes

Qualifier	Meaning
`UP`	UPC code (12 digits)
`SK`	SKU / Stock Keeping Unit
`VN`	Vendor part number
`IN`	Internal item number
`EZ`	Model number
`IZ`	Buyer's item number
`UI`	UPC case code

What to Send Orderful Support

If you've identified that your trading partner is sending transactions to you with missing product IDs and you cannot resolve it by updating the relationship configuration yourself, contact [email protected] with:

The Transaction ID from the failed transaction in Orderful
The complete error message including the JSON path
Your trading partner's name and ISA ID
Whether this is affecting all line items or specific ones

Frequently Asked Questions

My product has a UPC in our system, but the transaction is still failing. Why?
Your integration may be pulling from the wrong field, or the UPC may not be formatted correctly — it should be exactly 12 digits with no spaces or hyphens. Check the transaction payload in Orderful to see what value is actually being sent in the productServiceID field.

Do I need to send the same product IDs in my 810 invoice that I sent in the 850 purchase order?
Yes, in most cases. Your trading partner matches invoice line items to purchase order line items using the product identifiers. If they don't match, the invoice may be rejected or flagged for exception handling.
The exception is when product substitutions are allowed — in that case, your trading partner agreement will specify how substitutions should be identified.

Can I send multiple product identifiers per line item?
Yes — most trading partners allow or require multiple product identifiers per line item. They are sent in separate numbered paths (productServiceID, productServiceID1, productServiceID2, etc.), each paired with their own qualifier. Check your trading partner's guidelines in Orderful to see which identifiers they require.

This is failing for one trading partner but not others. Why?
Each trading partner configures their own product ID requirements. Check the guidelines for that specific relationship in Orderful — they may require a qualifier that other partners don't, or they may require multiple references per line item.

"Element is mandatory" Product ID Errors — Complete Fix Guide for EDI Transactions