# Invoice Document Type Codes: UNTDID 1001, X12 and EDIFACT Reference

> Source: https://netray.co/tools/ap-invoice-document-type-codes-reference
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Free Tools

## Short answer

Look up what invoice type codes such as 380, 381 and 389 mean, and map them to the X12 transaction sets and EDIFACT messages used for purchasing, shipping, invoicing and payment.

## Category

supply-chain

## Audience

- AP analyst
- EDI analyst
- ERP developer

## Tool

**Kind:** worksheet

**Mode:** reference

**Columns:**

#### Standard

**Key:** std

**Type:** text

#### Code

**Key:** code

**Type:** text

#### Name

**Key:** name

**Type:** text

#### Typical use in AP and purchasing

**Key:** use

**Type:** text

**Rows:**

#### Commercial invoice

**Std:** UNTDID 1001

**Code:** 380

**Use:** Standard supplier invoice; the default type in e-invoicing formats

#### Credit note

**Std:** UNTDID 1001

**Code:** 381

**Use:** Reduces the amount owed, for returns or price corrections

#### Debit note

**Std:** UNTDID 1001

**Code:** 383

**Use:** Increases the amount owed after an original invoice

#### Corrected invoice

**Std:** UNTDID 1001

**Code:** 384

**Use:** Replaces an earlier invoice with corrected data

#### Prepayment invoice

**Std:** UNTDID 1001

**Code:** 386

**Use:** Invoice for an advance payment before delivery

#### Self-billed invoice

**Std:** UNTDID 1001

**Code:** 389

**Use:** Invoice raised by the buyer on behalf of the supplier

#### Proforma invoice

**Std:** UNTDID 1001

**Code:** 325

**Use:** Preliminary invoice for customs or prepayment, not a payment demand

#### Partial invoice

**Std:** UNTDID 1001

**Code:** 326

**Use:** Invoice for part of the goods or services

#### Factored invoice

**Std:** UNTDID 1001

**Code:** 393

**Use:** Invoice assigned to a factoring company that must be paid to the factor

#### Invoice information for accounting purposes

**Std:** UNTDID 1001

**Code:** 751

**Use:** Information copy, not a payment request

#### Invoice

**Std:** ASC X12

**Code:** 810

**Use:** Electronic supplier invoice in North American EDI

#### Credit/Debit Adjustment

**Std:** ASC X12

**Code:** 812

**Use:** Adjusts a prior invoice amount

#### Payment Order/Remittance Advice

**Std:** ASC X12

**Code:** 820

**Use:** Payment and remittance detail from buyer to supplier

#### Application Advice

**Std:** ASC X12

**Code:** 824

**Use:** Reports acceptance or rejection of a business document at application level

#### Purchase Order

**Std:** ASC X12

**Code:** 850

**Use:** Order from buyer; first leg of three way match

#### Purchase Order Acknowledgment

**Std:** ASC X12

**Code:** 855

**Use:** Supplier confirms or changes the order

#### Ship Notice/Manifest

**Std:** ASC X12

**Code:** 856

**Use:** Advance ship notice (ASN) sent by the supplier

#### Purchase Order Change Request - Buyer Initiated

**Std:** ASC X12

**Code:** 860

**Use:** Buyer changes an open order

#### Receiving Advice/Acceptance Certificate

**Std:** ASC X12

**Code:** 861

**Use:** Buyer confirms receipt; supports evaluated receipt settlement

#### Purchase Order Change Acknowledgment/Request - Seller Initiated

**Std:** ASC X12

**Code:** 865

**Use:** Seller proposes or confirms order changes

#### Functional Acknowledgment

**Std:** ASC X12

**Code:** 997

**Use:** Confirms an EDI interchange was received and syntactically accepted

#### Invoice message

**Std:** UN/EDIFACT

**Code:** INVOIC

**Use:** EDIFACT equivalent of X12 810, includes credit notes by type code

#### Purchase order message

**Std:** UN/EDIFACT

**Code:** ORDERS

**Use:** EDIFACT equivalent of X12 850

#### Purchase order response message

**Std:** UN/EDIFACT

**Code:** ORDRSP

**Use:** EDIFACT equivalent of X12 855

#### Despatch advice message

**Std:** UN/EDIFACT

**Code:** DESADV

**Use:** EDIFACT equivalent of X12 856 ship notice

#### Receiving advice message

**Std:** UN/EDIFACT

**Code:** RECADV

**Use:** EDIFACT equivalent of X12 861

#### Remittance advice message

**Std:** UN/EDIFACT

**Code:** REMADV

**Use:** EDIFACT equivalent of X12 820 remittance detail

**Notes:** Code lists are maintained by UN/CEFACT, ASC X12 and trading partner agreements. Partners may restrict the subset they accept, so check the implementation guide your partner or e-invoicing network publishes.

## Content

**Intro:** Document AI that extracts invoices has to decide whether a page is an invoice, a credit note or a proforma, because each one posts differently. This table lists the standard type codes and the matching EDI messages in one place.

**Sections:**

#### How to use this table

**Body:** Search for the code that appears in a customer or supplier file, or the document name you want to classify. Use the UNTDID 1001 rows to map your OCR classification labels to standard codes, so that scanned PDFs and e-invoices end up with the same type values in your ERP. Use the X12 and EDIFACT rows to see which message belongs to which step of the order to cash or procure to pay flow.

#### Why the type code matters for posting

**Body:** A credit note must reverse the original posting, a prepayment invoice usually creates a down payment rather than a payable for goods, and a proforma should not be paid at all. If your classifier treats every document as a standard invoice, a credit note may be posted as a new payable. Add the type to your extraction output and route anything other than a standard invoice through its own approval path.

**Bullets:**

- 380: normal payable posting
- 381: reverse or offset the original invoice
- 384: replace the earlier invoice, avoid double posting
- 386: down payment handling
- 325: do not post, hold for the final invoice

#### Mapping to the three way match

**Body:** In a typical flow the purchase order (850 or ORDERS), the ship notice (856 or DESADV), the receiving advice (861 or RECADV) and the invoice (810 or INVOIC) are compared. Keeping the codes together helps when you design the document links that a matching rule needs to look up in your ERP.

#### Common mistakes

**Body:** Do not assume a document with the word Credit anywhere on it is a credit note, since terms and conditions often contain the word. Another error is treating a corrected invoice as a new one, which causes duplicate payments. Always carry the reference to the original invoice number for types 381 and 384.

**Cta:** If you want document classification and posting rules built around your ERP, Netray can design them to run privately on your own systems.

**Faq:**

#### What does invoice type code 380 mean?

**Answer:** Code 380 in UNTDID 1001 is a commercial invoice, the ordinary request for payment for goods or services. It is the default in many e-invoicing formats, including Peppol BIS Billing, where 381 is used for credit notes.

#### What is the difference between 381 and 383?

**Answer:** 381 is a credit note, which reduces the amount the buyer owes. 383 is a debit note, which increases it, for example when a supplier adds charges after the original invoice was issued.

#### Is X12 810 the same as EDIFACT INVOIC?

**Answer:** They serve the same purpose, an electronic invoice, but belong to different standards with different segment structures. 810 is used mostly in North America, INVOIC in Europe and by many global trading partners.

#### Should proforma invoices be posted in AP?

**Answer:** Normally not. A proforma invoice (325) is a preliminary document, often used for customs or prepayment. Hold it for approval and post only the final tax invoice unless your prepayment process says otherwise.

## Search terms

invoice type code 380, untdid 1001 invoice type codes, credit note type code 381, x12 810 invoice transaction set, edifact invoic message, peppol invoice type code, x12 transaction set numbers list

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json
