While maintaining master data is extremely important if a business is to experience streamlined B2B message exchange, it’s not always simple. The multitude of potential EDIFACT parties that can be involved in a transaction can be confusing and it’s imperative that certain processes are established and adhered to if costly errors are to be avoided.
Why master data errors happen
One of the most common sources of master data issues is the conflation of EDIFACT parties – i.e. the parties referenced in EDIFACT messages. To those inexperienced with EDI and EDIFACT, it may not seem like an issue to use certain EDIFACT parties interchangeably if the underlying information is the same for a certain transaction. However, just because Buyer and Ultimate consignee or Invoice recipient may be the same value in a B2B transaction with business partner A, for example, that doesn’t mean they always will be in all other B2B transactions with other business partners.
The two core principles one must adhere to here are:
- Always consult the respective EDI message implementation guideline and potentially accompanying documents, to check which partner role is required where.
- Always cross check with other document types in the same process choreography, to spot potential interdependencies. E.g. an INVOIC usually must contain the same role identifiers (AKA party codes) as the underlying ORDERS and DESADV. It may of course also contain additional role identifiers, not contained in the underlying document types.
Making the wrong assumptions and not cross-checking exactly with the requirements will ultimately lead to errors and the swift deterioration of your master data’s integrity.
Admittedly, setting up EDI connections with certain partners can be challenging, as you may encounter requirements, such as those 3M sends to their partners (pictured below).
In such cases it is even easier for users to confuse EDIFACT parties.
The impact of master data errors
Without trained personnel and processes and procedures in place to protect the integrity of your master data (such as conducting a full master data sync before onboarding a new partner), data quality is likely to deteriorate over time. In such situations, the only solution is a time-consuming audit and correction process.
Meanwhile, in the short term even the smallest error can have significant repercussions. For example, large consumers will often reject an invoice, no matter how big, if the data on it does not align with their records.
To help you avoid making expensive mistakes, in the following sections we will explore the subject of EDIFACT parties in detail, looking at the three popular EDIFACT subsets (EANCOM, EDITEC and VDA).
Before diving into these subsets, however, let’s first look quickly at EDIFACT as a whole…
Understanding EDIFACT and EDIFACT parties
UN/EDIFACT stands for the United Nations rules for Electronic Data Interchange for Administration, Commerce, and Transport. It is a set of internationally agreed standards that was created to facilitate the exchange of structured data between business partners.
As UN/EDIFACT is used across many different industries, the list of UN/EDIFACT parties (also known as “party function code qualifiers” and by the code “3035”) that can be used in B2B exchanges is very long. The full list of UN/EDIFACT party codes in the D01B version of the standard, which are used for the NAD (name and address) segments of EDI messages, can be found here.
As no company would ever need to use all of these party codes (and maintaining so many master data fields accurately would be virtually impossible), UN/EDIFACT users rely on standard subsets instead. These subsets are tailored towards specific industries and reduce the various EDI messages to essential fields that are mandatory to specific business processes or for specific message types. As a result, companies are only required to recognise and use a fraction of the available EDIFACT party codes.
Now let’s look at the key parties in each of these subsets and how they differ from one another, using the example of an INVOIC (invoice) transaction in each case.
EDIFACT subset 1: EANCOM (D01B INVOIC)
EANCOM is arguably one of the most popular subset of the UN/EDIFACT standard. Initially created for the retail industry, EANCOM is now also used by some other industries too.
The EANCOM standard currently includes about 50 different message types. For the purposes of this article look at one of these – the D01B INVOIC – as an example.
From the hundreds of parties available under the extensive UN/EDIFACT standard, the EANCOM D01B INVOIC guideline uses just 35. The most commonly used of these, and their descriptions, are listed below…
| Party code | Party | Party description |
| BY | Buyer | The party to which the merchandise/service is sold |
| DP | Delivery party | The party to which the goods should be delivered (if not the same as consignee/buyer) |
| IV | Invoicee | The party to which the invoice is issued |
| OB | Ordered by | The party that issued the order |
| PE | Payee | The credit party when not the beneficiary |
| PR | Payer | The party initiating payment |
| SF | Ship from | The party from where goods will be (or have been) shipped |
| SU | Supplier | The party supplying the goods or services |
| UC | Ultimate consignee | The party designated on the invoice or packing list as the final recipient of the stated merchandise |
In most EANCOM D01B INVOIC transactions you are unlikely to need to refer to any party outside the nine listed above. However, there are a number of others that may be required from time to time.
These less commonly used EDIFACT parties are listed below:
| Party code | Party | Party description |
| AB | Buyer’s agent / representative | The third party that arranged the purchase of merchandise on behalf of the buyer |
| BF | Beneficiary’s bank | The account servicer for the beneficiary or payee |
| CA | Carrier | The party undertaking or arranging transport of goods |
| CN | Consignee | The party to which goods are consigned |
| CO | Corporate office | The head office of a company |
| DL | Factor | A company offering a financial service whereby a firm sells or transfers title to its accounts receivable to the factoring company |
| DS | Distributor | The party distributing goods, financial payments or documents |
| FW | Freight forwarder | The party arranging the forwarding of goods |
| II | Issuer of invoice | The party issuing the invoice |
| ITO | Invoice recipient party (GS1 Code) | The party to which the invoice is sent and which processes the invoice on behalf of the invoicee (the invoicee can be different to the processing party) |
| LC | Party declaring the Value Added Tax (VAT) | The party responsible for declaring the Value Added Tax (VAT) on the sale of goods or services |
| LF | Buyer’s corporate office | The buyer’s head office |
| LG | Supplier’s corporate office | The supplier’s head office |
| LSP | Logistic Service Provider (GS1 Code) | A party providing logistic services for another party (e.g re-packing suppliers products) on products which may lead to added value for the product |
| MF | Manufacturer of goods | The party that manufactures the goods |
| MR | Message recipient | The party that receives a message |
| MS | Document / message issuer / sender | The party issuing a document and/or sending a message |
| N1 | Notify party no. 1 | The first party to be notified |
| N2 | Notify party no. 2 | The second party to be notified |
| NI | Notify party | The party to be notified of arrival of goods |
| PB | Paying financial institution | The financial institution designated to make payment |
| PW | Despatch party | The party where goods are collected or taken over by the carrier (if other than consignor) |
| RB | Receiving financial institution | The financial institution designated to receive payment |
| SF | Ship from | The party from where goods are being or have been shipped |
| SN | Store number | The number allocated to identify the store in question |
| SR | Supplier’s agent / representative | The party representing the seller for the purpose of the trade transaction |
| UD | Ultimate customer | The final recipient of the goods |
EDIFACT subset 2: EDITEC (INVOIC 4.1)
The EDITEC subset offers standards for the communication between the plumbing/heating/air conditioning industry (in German: SHK for Sanitär-Heizung-Klima) and the respective wholesale sector. This is also known as the Heating, Ventilation & Air Conditioning industry – better known as HVAC (although this does not include plumbing).
EDITEC’s INVOIC 4.1 standard uses six party function code qualifiers. These are listed below:
| Party code | Party | Party description |
| AB | Central regulator | The party, who settles the payment. Usually a central payment settlement company. |
| DP | Ship-to party | The party to which the goods should be shipped |
| IV | Invoice recipient | The party to which the invoice is issued |
| ST | Delivery address | The address the goods should be delivered to |
| SU | Manufacturer / Supplier (Industry) / Invoicing party | The supplier of the invoiced goods |
| WS | Wholesaler | The wholesaler |
EDIFACT subset 3: VDA (VDA 4938)
VDA stands for “Verband der deutschen Automobilindustrie” (German Automobile Industry Association). Unsurprisingly, given its name, VDA is almost used exclusively by the German automotive industry.
Within VDA’s INVOIC standard (VDA 4938) the ten most commonly used EDIFACT parties, or party function code qualifiers, are…
| Party code | Party | Party description |
| BY | Buyer | The party to which the goods are sold |
| II | Invoice issuer | The party that issues the invoice |
| IV | Invoicee | The party to which the invoice is issued |
| LC | Party declaring the Value Added Tax (VAT) | The party responsible on the supplier’s side for declaring the Value Added Tax (VAT) on the sale of goods |
| LD | Party recovering the Value Added Tax (VAT) | The party responsible on the customer’s side for recovering the Value Added Tax (VAT) on the sale of goods |
| MF | Manufacturer | The manufacturer of goods |
| PE | Payee | The credit party |
| SE | Seller | The party selling the goods |
| SF | Ship from | The party from where goods will be (or have been) shipped |
| ST | Ship to | The party to which the goods should be shipped |
Want more information?
If you would like help or advice on using EDIFACT parties correctly, avoiding master data issues or any other EDI topics, please get in touch. We are always happy to help!
You can also find a wide selection of articles, webinars, white papers and infographics in our resources section.
