Wednesday, March 4, 2026

What is EN 16931?

 What is EN 16931?

EN 16931 is the European standard defining the semantic data model for electronic invoices, published by CEN and mandated by EU Directive 2014/55/EU.

How EN 16931 Works

EN 16931 works on two levels:

1. Semantic Model (What)

The standard defines 162 business terms that an invoice can contain, organized into groups:

  • Invoice identification (number, date, type)
  • Seller and buyer information
  • Payment details
  • Tax information
  • Line items
  • Totals

2. Technical Syntaxes (How)

The semantic model can be expressed in two XML syntaxes:

  • UBL 2.1: Used by Peppol, XRechnung (UBL variant)
  • UN/CEFACT CII: Used by ZUGFeRD, Factur-X, XRechnung (CII variant)

CIUS: Country Extensions

Countries can create "Core Invoice Usage Specifications" (CIUS) that add rules without breaking EU compatibility. Examples:

  • XRechnung: German CIUS with Leitweg-ID requirement
  • Peppol BIS: Peppol's CIUS with network-specific rules

Why EN 16931 Matters

Legal Requirement

EU Directive 2014/55/EU mandates EN 16931 for public procurement. All EU governments must accept EN 16931-compliant invoices.

Cross-Border Interoperability

An EN 16931 invoice from Germany works in France, Italy, or any EU country. The standard ensures data can be understood regardless of the sender's software.

Future Mandate

ViDA (VAT in the Digital Age) will make EN 16931-based e-invoicing mandatory for all EU B2B transactions by 2030. Starting now puts you ahead.

How to Get Started

Step 1: Understand Your Requirements

Check which CIUS applies to your situation. Germany uses XRechnung, Belgium uses Peppol BIS, France uses Factur-X.

Step 2: Choose Your Syntax

UBL for Peppol/international; CII for ZUGFeRD/Factur-X. Both are equally compliant.

Step 3: Validate Compliance

Use validation tools to check both EN 16931 base rules and any CIUS-specific rules.

 

Sunday, February 15, 2026

What is ZUGFeRD?

 What is ZUGFeRD?

ZUGFeRD (Zentraler User Guide des Forums elektronische Rechnung Deutschland) is a hybrid e-invoice format that embeds machine-readable XML data inside a PDF/A-3 document. Open the file in a PDF reader — you see a normal invoice. Parse the embedded XML — you get structured data that an ERP can process automatically. ZUGFeRD 2.x and Factur-X are the same specification. They unified in 2020. The only difference is the name: ZUGFeRD is the German branding, Factur-X is the French. The underlying XML is CII (Cross Industry Invoice) D16B syntax, and the embedded file is always named factur-x.xml. The current version is ZUGFeRD 2.3.2 (aligned with Factur-X 1.07.2), released in late 2024. It’s EN 16931-compliant and accepted as a valid e-invoice format under Germany’s B2B mandate.

How ZUGFeRD Works

A ZUGFeRD invoice is a PDF/A-3 file with a structured XML attachment. The PDF/A-3 standard (ISO 19005-3) allows embedding arbitrary files inside a PDF — ZUGFeRD uses this to embed a CII XML file containing all the invoice data in machine-readable form.

The Dual-Readability Concept

When you open a ZUGFeRD invoice in any PDF reader (Adobe, Preview, browser), you see a normal, human-readable invoice. The visual layout, formatting, and branding are all there — exactly like a traditional PDF invoice.

When software processes the same file, it extracts the embedded XML attachment and reads the structured data directly. No OCR, no parsing, no guessing where the invoice number is. The data is typed, structured, and follows the EN 16931 data model.

This is what makes ZUGFeRD hybrid: one file serves both human readers and machine processors.

The XML Attachment

The embedded XML file is always named factur-x.xml (even in ZUGFeRD-branded invoices — this is part of the unified specification). The XML uses CII (Cross Industry Invoice) D16B syntax, which is one of the two syntaxes defined by EN 16931 (the other being UBL 2.1).

The XML is attached to the PDF via the PDF’s Associated File mechanism. The relationship type is set to Alternative — meaning the XML is an alternative representation of the same document content.

Why PDF/A-3 Specifically

Regular PDFs don’t allow embedded file attachments in a standards-compliant way. PDF/A-3 does. It’s the archival variant of PDF that:

  • Embeds all fonts (no missing character issues decades later)
  • Includes ICC color profiles
  • Allows associated file attachments (the XML)
  • Guarantees long-term readability without external dependencies

This matters for compliance. Tax authorities require invoice archives to be readable for 7–10+ years. PDF/A-3 guarantees this. A regular PDF with an XML attachment might not pass archive compliance checks.

Generating a ZUGFeRD Invoice

The production flow has four steps:

  1. Generate the visual PDF — your ERP’s existing PDF generation, but output as PDF/A-3 (not regular PDF). This means embedding fonts, including ICC profiles, and setting the PDF/A conformance level.
  2. Generate the CII XML — create the structured invoice data in CII D16B syntax with the correct ZUGFeRD profile (see profiles section below). The XML must be EN 16931-compliant.
  3. Embed the XML in the PDF — attach factur-x.xml to the PDF/A-3 file with the correct relationship metadata (AFRelationship = Alternative).
  4. Validate — check both the PDF/A-3 conformance and the CII XML validity against EN 16931 + profile rules. Validate a ZUGFeRD invoice →

Most ERP vendors handle steps 1–3 in their invoice output module. Step 4 is where a pre-submission compliance gate catches issues before the invoice reaches customers or archives.

Why ZUGFeRD Matters

ZUGFeRD Profiles Explained

ZUGFeRD defines six profiles, each adding more data fields than the last. The profile you choose determines what data must be present in the XML.

Profile

Data Depth

EN 16931 Compliant

Use Case

Minimum

Invoice metadata only

No

Archival, payment reference only

Basic WL

Header + totals, no line items

No

Basic accounting without line detail

Basic

Full line items with prices and quantities

No

Standard B2B invoicing

EN 16931 (Comfort)

Full EN 16931 data model

Yes

Cross-border EU, government invoicing

Extended

EN 16931 + additional fields

Yes (superset)

Complex scenarios (logistics, manufacturing)

XRechnung

German CIUS rules applied

Yes

German public sector invoicing

Which Profile Do I Need?

Sending to German government? Use XRechnung or EN 16931. The Minimum and Basic WL profiles are explicitly not accepted for the German B2B mandate — they lack required data fields.

Standard B2B in Germany? EN 16931 is the safe choice. It meets the mandate requirements and works cross-border. Basic works for domestic-only if you don’t need full EU compliance.

Cross-border EU trade? EN 16931. It’s the European standard — any EU trading partner’s system should process it.

France? EN 16931 (remember: ZUGFeRD 2.x = Factur-X, so the same profile works for French compliance).

Archival only? Minimum — but be aware this won’t meet Germany’s e-invoicing mandate requirements.

ZUGFeRD in Germany: Mandate Status

Germany’s e-invoicing mandate rolls out in three phases:

Date

Requirement

January 1, 2025

All businesses must be able to receive structured e-invoices (ZUGFeRD, XRechnung)

January 1, 2027

Businesses with revenue > €800,000 must send e-invoices

January 1, 2028

All businesses must send e-invoices

ZUGFeRD (profiles EN 16931, Extended, or XRechnung) is one of the accepted formats. XRechnung (pure XML without PDF wrapper) is the other. Both are valid.

During the transition period (2025–2026), paper and PDF invoices are still explicitly allowed for sending. But reception capability is already mandatory — your ERP must be able to ingest ZUGFeRD and XRechnung invoices now.

ZUGFeRD for ERP Vendors

If you maintain an ERP serving German businesses, ZUGFeRD support is on your roadmap. Here’s what matters:

PDF/A-3 output is the first hurdle. Most ERPs generate regular PDFs. Converting to PDF/A-3 requires font embedding, ICC profile inclusion, and conformance-level metadata. Libraries like Apache PDFBox, iText, or pdf-lib can handle this — but your existing PDF templates may need adjustments.

CII XML generation is the data challenge. Your ERP has the invoice data. The question is mapping it to CII D16B fields with the right profile. The EN 16931 data model defines ~180 business terms (BT-1 through BT-180+) — the profile determines which are required.

Embedding is the assembly step. Attach the XML to the PDF with the right metadata. This is a one-time implementation.

Validation is the ongoing concern. ERP templates drift across customers. Profile requirements change. Country-specific rules get updated. Validating every ZUGFeRD invoice before delivery catches issues before they become rejections.

Common ZUGFeRD Validation Errors

These are the errors we see most frequently in ZUGFeRD invoices:

PDF/A-3 conformance failures — The most common ZUGFeRD-specific error. The PDF isn’t valid PDF/A-3: missing embedded fonts, wrong color profile, or incorrect conformance level metadata. This is a PDF issue, not an XML issue — but the invoice is invalid without a conformant container.

BR-CO-10 — Sum of invoice line net amounts doesn’t match the invoice total. Rounding differences between the PDF (visual) and XML (structured) representations are the usual cause.

BR-DE-15 — Buyer reference missing. Required by the German CIUS (XRechnung rules). If you’re using the XRechnung profile, BT-10 must be populated.

BR-CO-18 — Tax amount calculation mismatch. The VAT breakdown in the XML doesn’t match the line-level or total-level tax amounts.

BR-DE-16 — Seller contact email missing. Another German CIUS requirement — the seller must provide a contact email address (BT-43).

Wrong profile declaration — The XML declares Minimum or Basic WL profile, but the sender intends EN 16931 compliance. Or the profile declared doesn’t match the data actually present. This causes validation rules to apply incorrectly.

ZUGFeRD vs Other Formats

ZUGFeRD vs XRechnung — ZUGFeRD is a hybrid (PDF + XML). XRechnung is pure XML. Both are EN 16931-compliant. ZUGFeRD gives you visual + machine-readable in one file; XRechnung is structured data only. For German B2B, both are accepted. For situations where the receiver needs a visual PDF, ZUGFeRD is the practical choice. 

ZUGFeRD vs Factur-X — They’re the same specification since 2020. ZUGFeRD is the German name, Factur-X is the French name. The XML structure, profiles, and validation rules are identical. If you implement one, you’ve implemented the other. 

ZUGFeRD vs UBL — Different XML syntaxes. ZUGFeRD uses CII (Cross Industry Invoice). UBL (Universal Business Language) is the other EN 16931-compliant syntax, used by Peppol and XRechnung. You can’t mix them — a ZUGFeRD invoice contains CII XML, never UBL. 

ZUGFeRD vs Peppol BIS — ZUGFeRD is a format (what the invoice looks like). Peppol is a network (how the invoice gets delivered). They serve different purposes, but they overlap: a ZUGFeRD CII invoice can be sent via Peppol (if the receiver’s Access Point supports CII syntax). In practice, most Peppol participants use UBL, not CII. 

How to Get Started

Step 1: Choose Your Profile

For most use cases: EN 16931. It meets Germany’s mandate, works cross-border, and is Factur-X-compatible for France. Only choose XRechnung profile if you’re specifically invoicing German government entities.

Step 2: Generate the PDF/A-3

Your PDF generation must output PDF/A-3 conformant files. Key requirements: all fonts embedded, ICC color profiles included, no transparency effects, no JavaScript, no encryption. Test PDF/A-3 conformance separately — a valid-looking PDF isn’t necessarily PDF/A-3 compliant.

Step 3: Generate the CII XML

Map your invoice data to CII D16B business terms. The EN 16931 profile requires: invoice number (BT-1), issue date (BT-2), currency (BT-5), seller and buyer identification, line items with amounts, and a complete VAT breakdown.

Step 4: Embed and Validate

Embed factur-x.xml in the PDF with AFRelationship = Alternative. Then validate the complete invoice — both the PDF/A-3 conformance and the CII XML against EN 16931 + profile rules + country CIUS.

 

Sunday, February 8, 2026

What is XRechnung?

 What is XRechnung?

XRechnung is Germany's national implementation (CIUS) of the EN 16931 European e-invoicing standard, mandatory for all public sector invoicing in Germany.

How XRechnung Works

XRechnung defines a strict XML structure based on the European standard EN 16931. It supports two syntaxes:

  • UBL 2.1 (Universal Business Language) — Most common, used by Peppol
  • UN/CEFACT CII (Cross-Industry Invoice) — Used by ZUGFeRD/Factur-X

German-Specific Rules

XRechnung adds 21 business rules beyond EN 16931, including:

  • Leitweg-ID: Required routing identifier for German government invoices
  • Payment terms: Specific format requirements
  • VAT categories: Mapping to German tax codes

Submission Methods

XRechnung invoices can be submitted via:

  • ZRE (Zentrale Rechnungseingangsplattform): Federal government portal
  • OZG-RE: State government portals
  • Peppol: Via certified Access Point
  • Email: To specific submission addresses (varies by authority)

Why XRechnung Matters

B2G: Already Mandatory

Since November 2020, all invoices to German federal authorities must be XRechnung-compliant. Most state governments have similar requirements. Non-compliant invoices may be rejected.

B2B: Coming 2025-2028

Germany's B2B e-invoicing mandate phases in:

  • January 2025: All businesses must receive EN 16931 invoices
  • January 2027: Businesses >€800K must send e-invoices
  • January 2028: All businesses must send e-invoices

XRechnung or ZUGFeRD are both accepted for the B2B mandate.

How to Get Started

Step 1: Check Your Requirements

Are you invoicing government (B2G) or only businesses (B2B)? Government requires XRechnung; B2B can use XRechnung or ZUGFeRD.

Step 2: Get Your Leitweg-ID

For government invoices, you need the recipient's Leitweg-ID routing number. This is usually provided on purchase orders or contracts.

Step 3: Generate or Convert

Use your accounting software's XRechnung export, or convert existing invoices

 

Sunday, February 1, 2026

What is Peppol?

 What is Peppol?

Peppol (Pan-European Public Procurement Online) is the dominant e-invoicing network in Europe. It’s a set of open specifications that define how businesses exchange electronic documents — invoices, credit notes, purchase orders — across borders, systems, and formats. Think of it as SMTP for invoices. Your ERP connects to a certified Access Point. The Access Point routes your invoice to the receiver’s Access Point. Both sides speak the same language (Peppol BIS Billing 3.0), regardless of what ERP, accounting system, or country either party operates in. Originally an EU-funded project launched in 2008 for public procurement, Peppol now covers B2B e-invoicing across 39+ countries with 300,000+ registered participants. As of 2026, Belgium, Germany, and Poland mandate Peppol for B2B transactions. France, Spain, and others are adding Peppol support alongside national systems.

How Peppol Works

The Four-Corner Model

Peppol uses a federated architecture called the four-corner model:

Corner 1: The sender (your business or your customer’s ERP)
Corner 2: The sender’s Access Point (certified Peppol service provider)
Corner 3: The receiver’s Access Point
Corner 4: The receiver

The sender’s ERP generates a Peppol BIS invoice and submits it to their Access Point. The Access Point looks up the receiver’s Peppol ID in the network’s directory (SML/SMP), finds the receiver’s Access Point, and delivers the invoice via the AS4 transport protocol. The receiver’s Access Point delivers the invoice to the receiver’s system.

No direct connection between sender and receiver is needed. No bilateral agreements. No format negotiation. As long as both sides have a certified Access Point and a registered Peppol ID, they can exchange documents.

Access Points

An Access Point is a certified service provider that connects your business to the Peppol network. It handles message routing, delivery receipts, and protocol compliance.

Access Points are certified by a Peppol Authority (one per country or region). Certification requires passing conformance tests for message handling, security, and SLA compliance.

As a business, you choose one Access Point. As an ERP vendor, you either become a certified Access Point yourself (significant investment, full control) or you integrate with an existing one via their API.

Most mid-market ERP vendors choose the second option. The Access Point handles the transport; the ERP vendor focuses on generating valid invoices.

Peppol IDs

Every participant on the Peppol network has a unique identifier. The format combines a scheme ID (identifying the type of identifier) with the actual value.

Common scheme IDs:

Scheme

Country

Identifier Type

0208

Belgium

KBO/BCE enterprise number

0106

Netherlands

KvK Chamber of Commerce number

9930

Germany

VAT number (USt-IdNr)

0007

International

GLN (Global Location Number)

0088

International

EAN Location Code

9906

Italy

Codice Fiscale

In UBL, a Peppol ID looks like this:

<cbc:EndpointID schemeID="0208">0123456789</cbc:EndpointID>

Getting the scheme ID wrong is one of the most common integration errors. The scheme must match the identifier type and the country. An invoice with a Dutch KvK number but scheme ID 9930 (German VAT) will be rejected.

SML and SMP (Service Discovery)

The Service Metadata Locator (SML) and Service Metadata Publisher (SMP) form Peppol’s directory system. When an Access Point needs to deliver an invoice, it queries the SML to find which SMP holds the receiver’s metadata, then queries the SMP to get the receiver’s Access Point URL and supported document types.

This happens automatically — you don’t interact with SML/SMP directly unless you’re building an Access Point.

Peppol BIS Billing 3.0

Peppol BIS (Business Interoperability Specification) Billing 3.0 is the invoice format specification. It’s a CIUS (Core Invoice Usage Specification) of EN 16931, meaning it takes the European e-invoicing standard and adds Peppol-specific rules on top.

The underlying syntax is UBL 2.1 (Universal Business Language). An alternative CII syntax exists but UBL is the default for most implementations.

Every Peppol invoice must pass:

  1. UBL 2.1 XML schema validation
  2. EN 16931 business rules (BR-01 through BR-65)
  3. Peppol-specific rules (PEPPOL-EN16931-R001 through R080)
  4. Country CIUS rules (if applicable — e.g., XRechnung for Germany, BEvCIUS for Belgium)

The specification identifier that goes in your invoice:

urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0

Full specification: docs.peppol.eu/poacc/billing/3.0

Why Peppol Matters

Where Peppol Is Mandatory (2026)

The mandate landscape is moving fast. Here’s where Peppol stands as of March 2026:

Country

Status

Peppol Role

Details

Belgium

Mandatory B2B (Jan 2026)

Required network

Grace period ended March 31

Germany

Reception mandatory (Jan 2025), sending phased 2027–2028

XRechnung delivered via Peppol

Largest EU market

Poland

KSeF mandatory

Peppol supported alongside KSeF

Dual-track system

France

Phased from Sep 2026

Supported via certified platforms (PDP)

Peppol is one of several options

Italy

FatturaPA mandatory

Peppol growing for cross-border

SDI remains dominant domestically

Netherlands

Voluntary, widely adopted

De facto standard

Highest Peppol adoption in EU

Norway

B2G mandatory

Required for public sector

Early Peppol adopter

Singapore

Nationwide e-invoicing

Peppol-based InvoiceNow

Asia-Pacific expansion

Australia / NZ

B2G pilots

Peppol-based eInvoicing

Growing adoption

 

Why ERP Vendors Need Peppol Support

If you build or maintain an ERP that serves EU businesses, Peppol support is no longer optional in most markets. The question isn’t whether to support it — it’s how to support it without breaking your existing invoice pipeline.

The common pitfall: adding Peppol as an afterthought. ERP generates a PDF or flat file, a converter turns it into UBL, and the result gets pushed to an Access Point. This works until it doesn’t — and it stops working exactly when your customer needs it most (month-end, audit, cross-border transaction with edge-case VAT rules).

The structural approach: validate every invoice against all four rule layers before it reaches the Access Point. Catch schema errors, missing fields, wrong scheme IDs, and rounding mismatches before they become rejections.

That’s what a pre-submission compliance gate does. It sits between your ERP export and the Access Point, and it makes sure nothing leaves your system that would get rejected on the other end.

Common Peppol Validation Errors

These are the errors we see most frequently in production Peppol pipelines:

PEPPOL-EN16931-R010 — Buyer reference is missing or invalid. Required for all Peppol invoices. Maps to BT-10 (Buyer Reference). Many ERPs leave this blank by default.

PEPPOL-EN16931-R001 — Business process identifier missing. The ProfileID element must contain the Peppol BIS 3.0 process identifier.

BR-CO-10 — Sum of invoice line net amounts doesn’t match the total. Usually a rounding issue — especially common with Belgian invoices after the 2026 rounding rule change.

BR-16 — Order reference missing when required. Some country CIUS rules make this mandatory (Germany’s BR-DE-15 requires a buyer reference for public sector invoices).

BR-CO-09 — VAT identifier prefix doesn’t match the country code. The VAT number must start with the correct two-letter country prefix.

 

Monday, January 26, 2026

ANSI X12 860 – Purchase Order Change Request (Buyer Initiated)

 The ANSI X12 860 – Purchase Order Change Request (Buyer Initiated) is generated when a buyer needs to modify an already-sent Purchase Order (X12 850) and must formally notify the supplier of those changes.

Below is a clear, real-world explanation of how and when the 860 is generated and sent, from both ERP and EDI perspectives.


🔹 When is X12 860 Generated?

An 860 is generated ONLY AFTER an 850 has already been sent and acknowledged.

Typical business triggers include:

1️⃣ Buyer Changes Order Details

Any change to an existing PO may trigger an 860:

  • Quantity increase/decrease

  • Price change

  • Delivery date change

  • Item substitution

  • Cancel or re-open PO lines

  • Add or delete line items

⚠️ If the buyer wants to cancel the entire PO, some trading partners require 860, others accept 855 with rejection.


2️⃣ ERP Event Trigger (System-Driven)

The 860 is usually triggered when:

  • Buyer updates PO in ERP (SAP / Oracle / NetSuite / JD Edwards)

  • Change status moves to “PO Change”

  • System compares Original PO vs Changed PO

  • Delta (difference) is identified

➡️ That delta is converted into X12 860


3️⃣ Supplier Has Not Yet Shipped

Most suppliers expect:

  • 860 BEFORE shipment

  • If shipment already occurred → 860 may be rejected


🔹 How X12 860 is Generated (Step-by-Step Flow)

🧩 End-to-End Flow

Buyer ERP
   ↓
PO Change Event
   ↓
ERP generates PO Change ID
   ↓
EDI Translator maps changes → X12 860
   ↓
EDI VAN / AS2 / SFTP
   ↓
Supplier EDI System

🔹 Step 1: Original PO Exists (850)

  • Buyer already sent X12 850

  • Supplier acknowledged via 855


🔹 Step 2: PO Change Happens in ERP

Example:

  • Qty changed from 100 → 120

  • Delivery date changed

ERP marks:

  • Change Version / Revision Number

  • Change Reason (optional)


🔹 Step 3: ERP → EDI Mapping Logic

EDI mapping:

  • Compares Old PO vs New PO

  • Identifies:

    • Changed lines

    • Added lines

    • Deleted lines


🔹 Step 4: X12 860 Creation

Key segments used:

SegmentPurpose
STTransaction Set Header
BCHBeginning Segment for PO Change
REFPO number / Change ID
DTMChange effective date
POCLine item change details
CTTTransaction totals
SETransaction trailer

🔹 Example BCH Segment

BCH*01*SA*4500001234**20260126~
  • 01 → Change order

  • SA → Standalone change

  • PO Number referenced


🔹 Example POC Segment (Quantity Change)

POC*01*120*EA*25.00**IN*ABC123~
  • 01 → Change

  • 120 → New quantity


🔹 How Is X12 860 Sent to Supplier?

🚚 Transmission Methods

  • AS2 (most common)

  • SFTP

  • VAN (SPS, OpenText, TrueCommerce)


🔁 Supplier Response After 860

ResponseMeaning
855Accept / Reject PO change
997Technical acknowledgment
856Shipment (if accepted)

🔹 Important Business Rules

⚠️ 860 vs 850

ScenarioDocument
New PO850
Modify existing PO860
Cancel PO (partner-dependent)860 or 855

⚠️ Partial Acceptance

  • Supplier may accept some lines and reject others

  • Reflected in 855 response


🔹 Real-World Example

Retail Buyer (Walmart / Target / Amazon)

  • Buyer sends 850

  • Inventory changes

  • Buyer updates ERP

  • 860 generated automatically

  • Supplier confirms via 855

  • Shipment continues with 856


🔹 Common Rejection Reasons

  • PO already shipped

  • Invalid line reference

  • Price change not allowed

  • Change window expired


🔹 Summary

✅ X12 860 is generated ONLY after an 850 exists
✅ Triggered by PO change in buyer ERP
✅ Contains only the changed lines (delta)
✅ Sent before shipment
✅ Supplier responds with 855



Sunday, August 31, 2025

Type of Invoices in EDI

 All Invoice Types, What They Are, and When To Use Them


Depending on the purpose of issuing, the type of industry, the type of transaction, legal requirements, and specific business needs, there are several types of invoices that businesses could use.


In order to ensure seamless transactions and receive accurate payments on time, it's crucial to use the appropriate invoice type that suits your business's needs.


Here's a summary of the main types of invoices and when to use them:


Types


What Is It


When To Use It


Standard Invoice


A general sales invoice 


Issued after goods or services have been provided


Commercial Invoice


An invoice used for customs clearance to assess import duties and taxes


When making international trade


Pro Forma Invoice


An initial invoice sent before the delivery of products or services


When providing a preliminary invoice to confirm the order


Past-due Invoice


An invoice reissued to collect overdue payment, often with additional late fees


When an invoice is past a due date


Retainer Invoice


An invoice issued to secure future services


For a work-for-hire contract, typically legal services


Interim Invoice


An invoice issued for partial payments


When requesting payment for a portion of the total cost of the project


Timesheet Invoice


An hour-based service invoice


For hourly services


Recurring Invoice


An invoice that is issued on a recurring basis, usually monthly or annually, for ongoing goods or services


For ongoing services, subscriptions or installments


Credit Invoice


An invoice for overpayment, returned products, refunds, cancellations, or other issues in the customer's favor


When credit is due to the customer


Debit Invoice


An invoice issued to collect any additional charge


When there is an additional charge or minor changes to the original invoice


Mixed Invoice


A combination of a credit and debit invoice


When there are both credits and debits to be applied to the customer's account


Final Invoice


A final invoice that concludes a business agreement and requests payment


After a project or service is completed or as a final follow-up of other invoices


E-invoice


Any invoice that is sent and received electronically


When an invoice in an electronic form is preferred or required


Now, let's take a closer look at each different type of invoice in detail.


Standard Invoice


A standard invoice is a regular sales invoice that provides the buyer with details of the purchase, including the total cost due and how to make the payment. This type of invoice often has a simple and flexible format that fits most industries. 


For most businesses, a standard invoice is a sufficient document to request payments for the purchased goods or services from the customers. The invoice also serves as legal proof of the transaction after the payment is completed. In addition to this, the seller may also provide a receipt of payment to confirm the transaction as well.


When to Use a Standard Invoice


When collecting payment from the customers.

Normally, an invoice would be sent to request the payment after the service was provided or the goods were delivered.

Example: BKB Industries produced and delivered 60 precision machine parts to the buyer and now needs to collect payment. BKB Industries can issue a standard invoice to the customer, outlining the quantity, unit price, and total amount for the machine parts, as well as providing payment details and terms, such as wire transfer within 30 days.


Commercial Invoice


A commercial invoice is an invoice that is mainly used in international trade. It is an important document for businesses that export and import goods to collect payment from abroad and for customs authorities to determine applicable import duties and taxes. Normally, a commercial invoice requests the final price of the goods or services, including all related expenses, such as shipping fees.


This type of invoice contains details of the purchase that are crucial to the customs process. Hence, businesses must be extremely cautious when creating one, as mistakes can cause delivery delays. 


It is mandatory to provide a commercial invoice when importing goods to some countries, and failure to do so may result in the goods being held at customs or returned to the sender. 


When to Use a Commercial Invoice


When shipping goods internationally and complying with international trade regulations.

Example: BKB Industries, a business based in Hong Kong, received an order from a client in Canada to produce 600 machine parts. In order to facilitate the customs process, BKB Industries includes a copy of a commercial invoice when shipping the products overseas to the client so the duties and taxes are calculated accordingly.


Pro Forma Invoice


A pro forma invoice, also spelled as a proforma invoice, is a preliminary invoice sent to the buyers before the delivery of goods or services. It includes details of the purchase, such as the products, estimated cost, logistic information, and more.


A pro forma invoice is a practical document to get an order confirmation from the buyers, as it allows the customer to review the purchase, estimate the cost, and negotiate terms. The seller and the buyer can use this invoice to communicate and ensure mutual agreement before finalizing the transaction.


Businesses in international trade can also issue a pro forma invoice to help estimate import duties and for customs purposes. However, it is different from a commercial invoice as a pro forma is not a legally binding document.


When to Use a Pro Forma Invoice


When confirming a large order with a customer.

When declaring the value of exporting or importing goods to customs.

When bidding on a project, a proforma invoice can be sent as part of a proposal.

A company that provides services to a foreign client may opt to send a pro forma invoice to the client before beginning any work.

Example: BKB Industries received an order of 60 precision machine parts. The company can send a pro forma invoice to the customer, stating the price per unit, the total cost, and any discounts. The customer can review if BKB Industries got the order correct, from the quantity ordered to the agreed price per unit, and then inform them to begin the manufacturing process without having to pay yet.


Past-due Invoice


A past-due or overdue invoice is an unpaid invoice that is past its payment period or specific due date. When the customer fails to pay on time, the supplier could reissue the invoice, send a reminder to notify the buyer of late fees or interest according to the payment terms, or take legal action.


When to Use a Past-due Invoice


An invoice of any type is automatically past-due when it is unpaid past the payment due date.

Example: BKB Industries has stated in the invoice that they expect payment within 30 days, but it has been 40 days from the invoice issue date, and they haven’t received any payment from the customer. In this case, BKB Industries can send a reminder notice to the customer, requesting a full payment as soon as possible with a $100 late fee.


💡 Tip: For businesses that often have to deal with past-due invoices, it might be time to review your invoice template if the details are stated clearly. For customers, setting up a reminder is one way to improve your invoice payment management. 


Retainer Invoice


A retainer invoice is an invoice for future service. Essentially, a retainer invoice requests a client to pay in advance for work that will be done in the near future or to secure a service to be used when needed. It can be thought of as a deposit or pre-payment to reserve services or to prevent cancellation. This invoice is often used for professional services like a consultant, advisor, lawyer, etc. 


A retainer invoice is often sent along with a legally binding retainer agreement.


When to Use a Retainer Invoice


When providing professional services.

When a retainer agreement is in place.

Example: A client needing legal assistance contacted BKB Legal Services. As the client does not know the exact period when the service would be required or how long they would need the service, BKB Legal Services sends a retainer invoice following a retainer agreement to the client to secure payments for the company and to make sure that a lawyer is available for the client's case.


Interim Invoice


While working on a large project, interim invoices help divide payments into smaller parts. They are sent at pre-agreed milestones during the project's progress, requesting payment for each completed portion. Interim invoices ensure vendor cash flow and avoid burdening the buyer with a hefty sum.


When to Use an Interim Invoice


When working on projects that take several months to complete, for example, construction projects, software development projects, and marketing campaigns.

Example: BKB Construction Services was contracted to work on a 12-month building project. To maintain an adequate supply budget, they agreed with the client to issue an interim invoice for payment upon completing every quarter of the total project.


Timesheet Invoice


A timesheet invoice is a hybrid of a timesheet and an invoice. It is used when the total cost of service is calculated based on the hours that the employee works to complete a project.


This invoice is commonly used by service-oriented businesses that charge customers for billable hours and is typically implemented throughout the project. A timesheet invoice usually records the start and end date of the project, the tasks, hourly charges, total hours, and total charges.


When to Use a Timesheet Invoice


When providing professional service and charging by hours.

Example: Let's say a consultant works at the standard rate of $150/hour. If hired to work for 20 hours, a consultant can issue a timesheet invoice requesting payment of $3,000.


Recurring Invoice


A recurring invoice is an invoice issued to the same customer for the same amount of money and for the same service at a regular intervals. Sometimes, a pre-agreed-upon payment is automatically deducted from the customer's account. 


If the customer fails to make a payment on time, the vendor might withhold the service or choose to cancel it for that payment term. 


This invoice is a convenient choice for businesses that offer subscriptions, such as internet service providers, streaming services, cleaning services, or food suppliers.


When to Use a Recurring Invoice


When the businesses deliver supplies or services regularly, like weekly cleaning or quarterly maintenance contracts.

When the business uses a subscription model where the same bill is sent out each period.

When the business requires payment in installments, such as car dealerships.

Example: BKB Cleaning Services provides a weekly cleaning package for apartments. They may send a recurring invoice to the clients every Friday to cover the service provided.


Credit Invoice


A credit invoice, also known as a credit memo or credit note, is a document used to notify a client that they are receiving reimbursement in the form of credits from the seller. This may follow invoice errors, customer overpayment, discounts, refunds, returned items, or order cancellation.


Regardless of the reasons the credit is offered, the seller should always generate a credit invoice to record the transaction.


This invoice always displays a negative total amount. For example, if a refund of $20 is issued, the credit invoice would be written as - $20 


When to Use a Credit Invoice


When there are issues in the customer's favor, such as damaged goods, order delays, missing order, etc. 

When there is an overpayment and credits need to be given back to the customer.

When a customer receives a discount after they have paid the full amount.

Example: The client received the machine parts they ordered from BKB Industries, but the delivery arrived 3 days later than expected, which caused a minor disruption in the company’s operation. BKB Industries then offers a $200 credit to the client to redeem in the next purchase.


Debit Invoice


A debit invoice, also known as a debit memo or debit note, is used to add additional charges to the outstanding amount or to make a minor adjustment after the invoice is issued and received.


Usually, the seller would issue a debit invoice to the buyer when the total charge has been increased. However, it can be used when a time-based service takes longer than expected, but it is important to inform the customer first.


When to Use a Debit Invoice


When the customer increases the quantity of their order

When there is a miscalculation of additional charges such as tax or delivery fees.

Example: BKB Industries already sent an invoice to the client requesting $2400 as a payment for the 60 machine parts they supplied. However, the delivery fees need to be recalculated, resulting in an additional cost of $80. They can send a debit invoice to the client for the additional charge.


Mixed Invoice


A mixed invoice includes the details of both credit and debit invoices and provides the accumulated total amount. The outstanding amount could be owed to either the buyer or the seller.


When to Use a Mixed Invoice


When errors favor the client and the buyer.

When you are combining credit and debit invoices.

When you need to decrease the amount the client owes but simultaneously increase it.

Example: BKB Industries issued a credit invoice worth $200 to the client and a debit invoice requesting an additional $80. In this case, BKB Industries can subtract the $80 fee from the $200 credit and send a mixed memo to inform the buyer of how they will repay the remaining $120.


Final Invoice


A final invoice is an invoice that concludes the total cost due for products or services rendered after deducting the amount charged by a retainer or interim invoice. It is usually sent to collect the remaining payment upon the completion of a project.


A final invoice includes details similar to a standard invoice, such as information about the product or service, invoice number, invoice date, and total amount. But if an amount was deducted prior to the end of the project, the business should address this in the invoice as well. 


When to Use a Final Invoice


When a project is complete.

When issuing a final payment agreement after a proforma invoice.

Example: After completing a building project, BKB Construction Services issues an invoice to the client, requesting the remaining amount after deducting the amount paid according to the interim invoices.


E-invoice


Electronic Invoice is an umbrella term referring to any invoices sent electronically, regardless of their specific types. For instance, as an attachment in an invoice email. 


When to Use an E-invoice


When an electronic invoice is preferred.

When a business wants the invoice to be conveniently shared among many stakeholders.

When a business uses an automated invoicing system.


 

Saturday, August 16, 2025

Type of ASN ( Advanced Shipment Notice)

 Advance Shipping Notice (ASN) is an electronic data interchange (EDI) message that a shipper sends to a receiver before a shipment leaves its origin. Since it is available before the shipment arrives, it allows recipients to make important decisions about their business in anticipation of adding the goods to their inventory, such as increasing staffing or addressing errors.

ASN referred to as an outbound ship notice, an outbound ship manifest, DESADV, or by its technical name, EDI 856.

What information does the ASN include?

The information may vary slightly determine on the trading partner requirements, but it generally includes:

• Order information, including the order number

• Delivery date and time

• Location information

• Pallet codes

• Product details

• Physical characteristics of the delivery, such as the type of packaging

• Carrier information

The ASN process

1. A shipment authorization is made to the supplier, usually in the form of a purchase order, but may also be presented as a planning schedule or shipping schedule.

2. The supplier sends the ASN to the receiving organization when the order is shipped.

3. The ASN then goes through the receiving open interface for verification. In transit and purchasing supplies are updated for successfully validated ASN lines. For each accepted line on the ASN, in transit supply is increased and purchasing supply is reduced. In the event that there is an error or discrepancy that causes the data to be not be accepted, an application advice, containing the most likely cause of the error, goes to the supplier. At that point, the supplier can send a new, corrected ASN.

4. The goods arrive at their destination. The ASN can be used to create receipts.

5. During the receipt transaction process, shipment vs. receipt quantities are compared. If there are any discrepancies, an application advice is sent to the supplier.

How the ASN helps

The ASN document helps buyers answer these questions:

• What order(s) have shipped?

• Which items are being shipped? How many have been shipped?

• When should the order arrive?

• Is the shipment the full order?

• Does the shipment have barcodes for easy receiving?

• What is the tracking number? Who is the delivery company? (This is helpful for dropship orders.)

Benefits

The ASN has many benefits, not just for supplier, but for retailer and distributor side, too.

For supplier:

• Minimize order to payment cycles.

• Track shipments and quickly address damages or missing goods.

• Improve accuracy and reduce stock-outs.

• Move products to their destinations faster.

For retailer and distributor:

• Reduce the costs of receiving goods through efficient scheduling.

• Boost speed and accuracy.

• Minimize safety stock requirements.

• Address problems before arrival.


 1. Pick and Pack ASN


>> Structure: Shipment → Order → Pack → Item

>> Used when each order is picked, packed into cartons/pallets, and shipped together.

>> Common in retail and automotive industries.

>> Includes detailed packing hierarchy (cartons, pallets, items).


 2. Standard (Shipment-Level) ASN


>> Structure: Shipment → Order → Item

>> Simplest ASN format—no detailed packaging information.

>> Used when packing details are not required.

>> Only item-level information is shared.


 3. Pack-Level ASN


>> Structure: Shipment → Pack → Item

>> Focuses on carton/pallet-level packing without order breakdown.

>> Used in scenarios where shipment contains multiple cartons/pallets but order-level details are not critical.


 4. Mixed ASN


>> Structure: Shipment → Mixed Packs → Items from Multiple Orders

>> Used when cartons/pallets contain items from multiple purchase orders.

>> Common in consolidation shipments.


 5. Pallet ASN


>> Structure: Shipment → Pallet → Item

>> Used for palletized shipments.

>> Often uses License Plate Numbers (LPN/SSCC) for tracking pallets.


 6. Drop Ship ASN


>> Structure: Shipment → Customer Direct Delivery → Item

>> Used when the supplier ships directly to the customer on behalf of a retailer or distributor.


 7. Cross-Docking ASN


>> Structure: Shipment → Cross-Dock Location → Item

>> Used in cross-docking operations where goods are not stored but transferred immediately.


 8. Consolidated ASN


>> Combines multiple shipments into a single ASN for easier processing.

>> Often used in 3PL or hub-and-spoke logistics.

Saturday, August 9, 2025

X12 (ANSI) ASN and EDIFACT DESADV

 Here’s a comprehensive breakdown covering both X12 (ANSI) ASN and EDIFACT DESADV formats, along with hierarchical structures (HL vs CPS/PAC) and sample documents to help you visualize how they correspond.


1. ANSI X12 856 ASN — Structure & Sample

Hierarchical Structure (HL Loops)

The ANSI X12 856 uses a nested HL (Hierarchical Level) structure with these loops:

  • S – Shipment

  • O – Order

  • T – Tare (Pallet)

  • P – Pack (Carton)

  • I – Item
    This hierarchy flexibly supports various ASN types (Pick-and-Pack, Pallet, Mixed, etc.).

Sample 856 ASN (Generic)

ISA...
GS...
ST*856*0001~
BSN*00*SHIPMENTID*20231014*1831~
HL*1**S~
TD1*CTN25*24...
TD5*...
REF*BM*...
DTM*011*20231014~
N1*ST*...~
HL*2*1*O~
PRF*0123456789~
TD1*...
N1*BY*...~
HL*3*2*P~
MAN*GM*...~
HL*4*3*I~
LIN**IB*PRODUCT1...
SN1**24*EA~
...
CTT*1*5~
SE*36*0001~
GE*...
IEA*...

This example illustrates shipment with nested order, pack, and item loops.


2. EDIFACT DESADV — Structure & Sample

Hierarchical Structure (CPS & PAC)

EDIFACT DESADV uses:

  • CPS (Consignment Packing Sequence) — defines packaging hierarchy (e.g., pallet vs carton)

  • PAC (Package) — details packaging units

  • LIN (Line Item) — specifies items inside packages

Relationships among CPS levels use:

  • CPS-01 — unique ID

  • CPS-02 — parent ID (hierarchical nesting)

  • CPS-03 — packaging level (e.g., 1 = inner, 3 = outer)

DESADV Sample (Simple)

UNH+54321+DESADV:D:01B:UN:EAN011+2.0'
BGM+351::9:WAREHOUSE+DEL12345:9'
DTM+137:20200203'
NAD+BY+...:9'
NAD+SU+...:9'
CPS+1'
PAC+1'
CPS+2+1'
PAC+1++201'
PCI+30'
GIN+BJ+123456789012345675'
LIN+1++40700719670720:SRV'
QTY+12:21'
UNT+29+54321'

This shows a nested packaging structure (CPS with PAC) and item detail (LIN/QTY).

DESADV Sample (Detailed with Multiple Levels)

UNH+1+DESADV:D:96A:UN:A01051
BGM+351+12345
DTM+137:200905050506:203
NAD+... (carrier/buyer/seller)
TDT...
CPS+1++1
PAC+4
QTY+52:48:PCE
LIN+++1234:IN
QTY+12:192:PCE
RFF+ON:...
CPS+2++1
PAC+10
...
CPS+3++3
PAC+2++PLT1::92
UNT+34+1
UNZ+1+31

This shows pallets and cartons (nested under CPS), with item quantities and references.


3. Comparative Mapping: X12 vs EDIFACT

Logical Level X12 (856 HL Loop) EDIFACT (DESADV)
Shipment HL S UNH → BGM / header segments
Order HL O NAD / RFF segments (order ref)
Pallet/Tare HL T CPS (packaging level = outer = 3)
Carton/Pack HL P CPS + PAC (packaging level = inner)
Item HL I LIN + QTY
Hierarchy Tracking HL with parent pointer CPS-02 parent ID field

4. Visual Flow Diagrams (Text Sketch)

ANSI X12 ASN Flow

Shipment (HL S)
 └ → Order A (HL O)
      └ → Pack 1 (HL P) → Item 1, Item 2 (HL I)
      └ → Pack 2 (HL P) → Item 3 (HL I)
 └ → Order B (HL O)
      └ → Pack 3 (HL P) → Item 4 (HL I)

EDIFACT DESADV Flow

CPS 1 (Pallet Level, level=3)
 └ PAC / packaging info
 └ GIN / item identifier
 └ CPS 2 (Carton inside Pallet, level=1)
      └ PAC
      └ LIN / Item detail
 └ CPS 3 (Another Carton)
      └ PAC
      └ LIN