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.

 

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.

 

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.

 

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.

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

VDA EDI Standard

 VDA stands for Verband der Automobilindustrie (German Association of the Automotive Industry). It is a highly specialized Electronic Data Interchange (EDI) standard developed and primarily used by the German automotive industry. This includes major players like Volkswagen, Audi, Bosch, Continental, and Daimler AG, and their extensive network of suppliers.

VDA EDI standards facilitate the seamless exchange of business documents, enabling critical manufacturing methodologies like Just-In-Time (JIT) and Lean Manufacturing by ensuring precise inventory management and rapid responses to demand changes.

Important Things to Focus on for VDA EDI Standard:

1. Fixed Format Structure:

   • Unlike other EDI standards like EDIFACT or ANSI X12 which often use delimiters and segments, VDA messages traditionally employ a fixed-length flat file format. This means each data element occupies a predefined number of characters, and the position of the data within the message is crucial for interpretation.

   • While older VDA messages are fixed-format, it's important to note that newer VDA standards are increasingly adopting the EDIFACT format to align with international standards and allow for greater flexibility and scope of data. Always confirm with your trading partner which specific VDA version and format they require.

2. Automotive Industry Specificity:

   • VDA is deeply ingrained in the German automotive supply chain. Its message types are tailored to the unique processes and requirements of car manufacturers and their suppliers. This includes detailed messages for call-offs, delivery schedules, dispatch advice, invoices, and more.

3. Key VDA Message Types:

   • You'll encounter various VDA message numbers, each corresponding to a specific business document. Some of the most common include:

     • VDA 4905: Legacy Delivery Call-off (often being replaced by VDA 4984).

     • VDA 4913 / VDA 4987: Delivery Note / Despatch Advice (critical for goods receipt and transport data). VDA 4987 is the newer version replacing 4913.

     • VDA 4915: Detailed Call-Off (for Just-in-Time - JIT - scenarios).

     • VDA 4920: Forwarding Instruction / Shipping Order.

     • VDA 4925: Purchase Order.

     • VDA 4906 / VDA 4938: Invoice.

     • VDA 4907: Remittance Advice.

     • VDA 4984: Planning Schedule (the modern replacement for VDA 4905).

     • VDA 4971: Collection Order.

4. Communication Protocols:

   • OFTP (Odette File Transfer Protocol), particularly OFTP2, is a widely used and recommended communication protocol for exchanging VDA EDI messages within the automotive industry, especially in Europe. It provides secure and reliable data transfer. Other protocols like AS2, SFTP, or VANs (Value Added Networks) might also be used, depending on the trading partner.

5. Strict Adherence to Guidelines:

   • VDA standards come with very specific implementation guidelines (MIGs - Message Implementation Guides) provided by each trading partner (OEMs like Daimler, VW, etc.). These guides detail the exact structure, data elements, codes, and business rules for each message type. Deviations can lead to rejections and delays.

6. Partner-Specific Variations:

   • Even within the VDA standard, different automotive manufacturers (OEMs) or Tier 1 suppliers may have their own specific interpretations or extended requirements for certain messages. This means that an implementation for one VDA trading partner might not be 100% transferable to another. It's crucial to obtain and meticulously follow each partner's specific VDA guidelines.

7. Transition to EDIFACT-based VDA:

   • As mentioned, the VDA is moving towards using EDIFACT as the underlying technical format for newer VDA messages (e.g., VDA 4984 is based on EDIFACT DELFOR). This brings VDA more in line with global EDI standards and offers more flexibility. Be aware of whether your trading partner expects legacy VDA flat files or the newer EDIFACT-based VDA messages.

8. Testing and Validation:

   • Thorough testing with each trading partner is paramount. This includes sending test files, receiving acknowledgments, and validating the data content to ensure accuracy and compliance with their specific requirements. Many OEMs provide validation portals or test environments for this purpose.

9. Error Handling and Monitoring:

   • Implement robust error handling mechanisms to quickly identify and address any issues with VDA message processing. Continuous monitoring of EDI transactions is essential to ensure smooth data flow and prevent disruptions in the supply chain.

Here's a conceptual flow for a common VDA EDI scenario, typically focusing on a Call-Off/Delivery Process between an OEM (Original Equipment Manufacturer - e.g., BMW, VW) and a Supplier:

---

Conceptual VDA EDI Flow Diagram Description: OEM to Supplier (Call-Off & Delivery)

Goal: To illustrate the typical exchange of VDA messages for demand planning, delivery, and invoicing in the automotive supply chain.

Key Participants:

1. OEM (Original Equipment Manufacturer): The Car Manufacturer (e.g., Volkswagen, Audi).

2. Supplier: The component manufacturer or parts supplier.

3. EDI/Integration Platform: The system responsible for transforming, routing, and translating EDI messages (could be on-premise or cloud-based).

---

Flow Description (Left to Right, with Interactions):

Phase 1: Demand Planning & Call-Off

1. OEM's ERP/Planning System (Source):

   • Generates demand forecasts and production schedules.

   • Triggers the creation of a VDA 4984 (Planning Schedule / DELFOR) or older VDA 4905 (Delivery Call-off) message.

2. OEM's EDI/Integration Platform (Processing):

   • Receives data from the ERP.

   • Maps and transforms the data into the specific VDA 4984/4905 format (fixed-length or EDIFACT-based).

   • Adds necessary control segments and partner information.

3. Communication Channel (OFTP2/AS2/SFTP/VAN):

   • Securely transmits the VDA 4984/4905 message from the OEM's platform to the Supplier's platform.

4. Supplier's EDI/Integration Platform (Receiving & Processing):

   • Receives the VDA 4984/4905 message.

   • Validates the message structure and content.

   • Transforms the VDA data into a format understandable by the Supplier's ERP/Planning system (e.g., XML, flat file, direct database insert).

5. Supplier's ERP/Planning System (Target):

   • Receives and processes the planning schedule/call-off data.

   • Updates inventory, production schedules, and material requirements.

   • May trigger internal production orders or material procurement.

Phase 2: Delivery & Shipping

6. Supplier's Warehouse/Logistics System (Source):

   • Based on the call-off, components are picked and packed for shipment to the OEM.

   • Generates internal shipping documents.

7. Supplier's EDI/Integration Platform (Processing):

   • Receives shipping data from the Warehouse/Logistics system.

   • Creates a VDA 4987 (Despatch Advice / DELJIT) or older VDA 4913 (Delivery Note) message. This message contains details like parts, quantities, batch numbers, transport information (container ID, carrier, expected delivery time).

8. Communication Channel (OFTP2/AS2/SFTP/VAN):

   • Securely transmits the VDA 4987/4913 message from the Supplier's platform to the OEM's platform.

9. OEM's EDI/Integration Platform (Receiving & Processing):

   • Receives the VDA 4987/4913 message.

   • Validates the message.

   • Transforms the VDA data into a format for the OEM's systems.

10. OEM's Goods Receipt/Warehouse Management System (Target):

    • Receives the advance shipping notice (ASN).

    • Prepares for incoming goods. This is crucial for Just-In-Time (JIT) delivery, allowing the OEM to know what's arriving and when, optimizing their receiving docks and production lines.

    • Upon physical receipt, the system validates the physical goods against the electronic VDA 4987/4913 data.

Phase 3: Invoicing & Payment (Optional, but common)

11. Supplier's Invoicing/Finance System (Source):

    • Generates an invoice based on the delivered goods and agreements.

12. Supplier's EDI/Integration Platform (Processing):

    • Creates a VDA 4906 / VDA 4938 (Invoice) message.

13. Communication Channel (OFTP2/AS2/SFTP/VAN):

    • Transmits the VDA 4906/4938 message to the OEM.

14. OEM's EDI/Integration Platform (Receiving & Processing):

    • Receives and validates the VDA Invoice.

15. OEM's Accounts Payable/ERP System (Target):

    • Processes the invoice, often performing a 3-way match (Purchase Order - implicitly covered by call-offs, Goods Receipt, and Invoice) for automated payment processing.