Thursday, February 13, 2025

Different Type of Invoices used in EDI

 Invoices in Electronic Data Interchange (EDI) vary depending on the EDI standard being used. Below is a comparison of different types of invoices across major EDI standards:


1. ANSI X12 (North America)

EDI Document Description
810 Invoice Standard invoice sent by a seller to a buyer requesting payment.
880 Grocery Products Invoice Used in the grocery industry to invoice trading partners.
894 Delivery/Return Base Record Used in direct store delivery to invoice for delivered or returned goods.
896 Product Catalog and Sales Data Report Used for invoicing in the book and publishing industry.

2. EDIFACT (International)

EDI Message Description
INVOIC (Invoice Message) Used for standard invoicing across industries.
CREMUL (Credit/Debit Advice Message) Provides details of multiple credit or debit transactions.
DEBADV (Debit Advice Message) Sent by a buyer to inform the supplier of a debit entry.
REMADV (Remittance Advice Message) Used to notify the recipient about payments made.

3. PEPPOL (Europe & Asia)

EDI Message Description
BIS Billing 3.0 Invoice Standard e-invoice format under PEPPOL.
BIS Credit Note 3.0 Used to issue credit notes for returned or disputed invoices.

4. TRADACOMS (UK)

EDI Message Description
INVOIC (Invoice Message) Standard invoice message for UK retail and business transactions.
CREDIT (Credit Note Message) Used to issue credit against previous invoices.

5. VDA (Germany – Automotive Industry)

EDI Message Description
VDA 4906 (Invoice) Standard invoice for the German automotive industry.

Here are more examples of invoices used in different EDI standards across various industries:


1. ANSI X12 (North America)

EDI Document Description Industry
810 Invoice Standard invoice for billing. General
811 Consolidated Service Invoice/Statement Used for billing multiple services in a consolidated format. Telecom, Utilities
812 Credit/Debit Adjustment Used for invoice adjustments, refunds, or disputes. General
813 Electronic Filing of Tax Return Data Used to transmit tax return information. Government
820 Payment Order/Remittance Advice Contains payment details and remittance information. Banking, Finance
875 Grocery Products Purchase Order Invoice Invoice for grocery industry orders. Retail, Grocery
880 Grocery Products Invoice Used in food and grocery supply chain. Retail, Grocery
882 Direct Store Delivery Summary Summary of invoices for direct store delivery. Retail
894 Delivery/Return Base Record Used for invoicing and returns in direct store delivery. Consumer Goods
896 Product Catalog and Sales Data Report Used for sales-based invoicing in publishing. Books, Publishing

2. EDIFACT (Global)

EDI Message Description Industry
INVOIC Standard invoice message. General
CREMUL (Credit Advice Message) Notifies multiple credit transactions. Finance, Banking
DEBADV (Debit Advice Message) Debit note notification. Finance, Banking
REMADV (Remittance Advice Message) Sent to inform the supplier of a payment. Finance, B2B Payments
PAYMUL (Multiple Payment Order) Includes multiple payment orders for invoices. Banking, Finance
ORDERS (Purchase Order) Sometimes includes pro-forma invoicing information. General

3. PEPPOL (Europe & Asia)

PEPPOL BIS Document Description Industry
BIS Billing 3.0 Invoice Standard invoice format. General
BIS Credit Note 3.0 Used for credit notes. General
BIS Self-Billing Invoice Used when the buyer generates the invoice on behalf of the supplier. Retail, Manufacturing

4. TRADACOMS (UK Retail & Business)

TRADACOMS Message Description Industry
INVOIC (Invoice Message) Standard invoice. Retail
CREDIT (Credit Note Message) Credit note for adjustments. Retail

5. VDA (Germany – Automotive)

VDA Message Description Industry
VDA 4906 Invoice Standard invoice message for automotive suppliers. Automotive

6. Other Industry-Specific EDI Invoices

Standard Invoice Type Industry
HIPAA EDI 837 Healthcare invoice for insurance claims. Healthcare
UBL 2.1 Invoice Universal Business Language Invoice. Government, EU
OAGIS Invoice Invoice format used in Open Applications Group. Manufacturing, Supply Chain


Monday, February 10, 2025

ASN with X12-856 and EDIFACT DESADV Comparison

 In X12 EDI, the HL (Hierarchical Loop) structure is similar to the DESADV (Despatch Advice) message in EDIFACT. The HL segment in X12 allows for a hierarchical breakdown of a shipment, similar to how DESADV organizes its data.


πŸ“Œ HL in X12 vs. DESADV in EDIFACT

Concept X12 HL Segment (Hierarchical Loop) EDIFACT DESADV (Despatch Advice)
Purpose Represents hierarchical levels (e.g., Shipment → Order → Item → Packaging) Provides shipping & delivery details
Structure Uses HL segments to define hierarchy Uses CPS (Consignment Packaging Sequence) and LIN (Line Item)
Flexibility Can have multiple levels (Shipment, Order, Item, etc.) Uses segments like CPS, LIN, MEA
Typical Message 856 (ASN - Advanced Ship Notice) DESADV (Despatch Advice)

πŸ“Œ Example: X12 856 (ASN) with HL Segments

This example represents a Shipment → Order → Item hierarchy in X12:

ISA*00*          *00*          *12*SENDER        *12*RECEIVER      *210118*1545*U*00401*000000001*0*P*>~
GS*SH*SENDER*RECEIVER*20240118*1545*1*X*004010~
ST*856*0001~
BSN*00*123456*20240118*1545~
HL*1**S~   ➝ Shipment Level
  TD1*CTN*5*KG*200~ 
  TD5*B*2*UPSN~
  REF*BM*SHIPMENT123~
HL*2*1*O~   ➝ Order Level (inside shipment)
  PRF*PO123456~
HL*3*2*I~   ➝ Item Level (inside order)
  LIN*1*UP*1234567890123~
  SN1*1*10*EA~
SE*12*0001~
GE*1*1~
IEA*1*000000001~

Key Takeaways:

  • HL*1**S~Shipment level
  • HL*2*1*O~Order level (inside shipment)
  • HL*3*2*I~Item level (inside order)

πŸ“Œ Equivalent in EDIFACT DESADV

Similar data in DESADV (EDIFACT format) would look like this:

UNH+1+DESADV:D:96A:UN'  
BGM+351+123456+9'  
DTM+11:20240118:102'  
MEA+WT++KG:200'  
CPS+1'    ➝ Shipment Level  
  PAC+5++CTN'  
CPS+2+1'   ➝ Order Level  
  RFF+ON:PO123456'  
CPS+3+2'   ➝ Item Level  
  LIN+1+UP:1234567890123'  
  QTY+12:10:EA'  
UNT+12+1'  

Key Takeaways:

  • CPS+1'Shipment level
  • CPS+2+1'Order level (inside shipment)
  • CPS+3+2'Item level (inside order)

πŸ“Œ

The HL (Hierarchical Loop) in X12 is equivalent to the CPS (Consignment Packaging Sequence) in DESADV. Both structures provide a way to organize shipment, order, and item details in a hierarchical manner.

πŸ“Œ Mapping X12 HL (Hierarchical Loop) to EDIFACT DESADV CPS

To map X12 856 (ASN) HL segments to EDIFACT DESADV CPS, we follow these steps:


1️⃣ Hierarchy Mapping: X12 HL vs. DESADV CPS

X12 856 (ASN) HL Loop EDIFACT DESADV CPS Equivalent Notes
HL*1**S~ (Shipment) CPS+1' Shipment level
HL*2*1*O~ (Order) CPS+2+1' Order level (inside shipment)
HL*3*2*I~ (Item) CPS+3+2' Item level (inside order)
TD1 (Package) PAC Packaging details
TD5 (Carrier) TDT Transport details
REF (Reference) RFF Reference numbers (BOL, PO, etc.)
LIN (Item) LIN Line Item
SN1 (Item Quantity) QTY Quantity

2️⃣ Example Mapping: X12 856 → DESADV

Here’s an example of X12 HL loops mapped to CPS structures in DESADV.

πŸ”΅ X12 856 (ASN) Sample

ISA*00*          *00*          *12*SENDER        *12*RECEIVER      *210118*1545*U*00401*000000001*0*P*>~
GS*SH*SENDER*RECEIVER*20240118*1545*1*X*004010~
ST*856*0001~
BSN*00*123456*20240118*1545~
HL*1**S~   ➝ Shipment Level
  TD1*CTN*5*KG*200~ 
  TD5*B*2*UPSN~
  REF*BM*SHIPMENT123~
HL*2*1*O~   ➝ Order Level (inside shipment)
  PRF*PO123456~
HL*3*2*I~   ➝ Item Level (inside order)
  LIN*1*UP*1234567890123~
  SN1*1*10*EA~
SE*12*0001~
GE*1*1~
IEA*1*000000001~

🟒 Equivalent EDIFACT DESADV

UNH+1+DESADV:D:96A:UN'  
BGM+351+123456+9'  
DTM+11:20240118:102'  
MEA+WT++KG:200'  
TDT+20++UPSN'  
RFF+BM:SHIPMENT123'  

CPS+1'    ➝ Shipment Level  
PAC+5++CTN'  

CPS+2+1'   ➝ Order Level  
RFF+ON:PO123456'  

CPS+3+2'   ➝ Item Level  
LIN+1+UP:1234567890123'  
QTY+12:10:EA'  

UNT+12+1'  

3️⃣ Detailed Segment Mapping

X12 Segment DESADV Equivalent Description
BSN*00*123456*20240118*1545~ BGM+351+123456+9' ASN Number
DTM+11:20240118:102' DTM+11:20240118:102' Shipment Date
TD1*CTN*5*KG*200~ PAC+5++CTN' + MEA+WT++KG:200' Packaging details
TD5*B*2*UPSN~ TDT+20++UPSN' Carrier Information
REF*BM*SHIPMENT123~ RFF+BM:SHIPMENT123' Shipment Reference
HL*1**S~ CPS+1' Shipment Level
HL*2*1*O~ CPS+2+1' Order Level
PRF*PO123456~ RFF+ON:PO123456' Purchase Order
HL*3*2*I~ CPS+3+2' Item Level
LIN*1*UP*1234567890123~ LIN+1+UP:1234567890123' Line Item
SN1*1*10*EA~ QTY+12:10:EA' Quantity

4️⃣ Key Takeaways

HL Loops in X12 map directly to CPS sequences in DESADV
TD1 (Packaging) → PAC, TD5 (Carrier) → TDT, REF (References) → RFF
Item-level details like LIN & QTY are mapped accordingly


Saturday, February 8, 2025

EInvoice - Key Difference of ZuGFERD - Germany Standard.

 

πŸ“Œ Key Differences Between ZUGFeRD Versions

ZUGFeRD (Zentraler User Guide des Forums elektronische Rechnung Deutschland) is a hybrid e-invoicing format that combines a PDF/A-3 file with an embedded XML invoice based on the CII (Cross-Industry Invoice) standard from UN/CEFACT. Each version of ZUGFeRD has differences in the CII XML structureelements, and schema versions. Here's a comparison of the key differences across versions:


πŸ“œ Overview of ZUGFeRD Versions

Version Release Year XML Standard Major Changes
ZUGFeRD 1.0 2014 CII (Cross Industry Invoice) First version, hybrid PDF/A-3 + CII XML.
ZUGFeRD 2.0 2019 EN 16931 (EU Standard) + CII Fully compliant with European XRechnung standards.
ZUGFeRD 2.1 / Factur-X 1.0 2020 EN 16931 + CII & UBL Added UBL XML support, aligned with Factur-X (France).
ZUGFeRD 2.2 / Factur-X 1.0.06 2022 EN 16931 + CII & UBL Minor fixes, better PEPPOL integration.
ZUGFeRD 2.2.1 2023 EN 16931 + CII & UBL Small refinements for international use.

πŸ” Key Differences in XML Structures

1️⃣ ZUGFeRD 1.0 (2014) – Basic CII XML

  • Based on CII (Cross Industry Invoice) XML.
  • Does not support UBL.
  • Example:
    <rsm:CrossIndustryInvoice>
        <ram:ExchangedDocument>
            <ram:ID>INV-10001</ram:ID>
        </ram:ExchangedDocument>
    </rsm:CrossIndustryInvoice>
    

2️⃣ ZUGFeRD 2.0 (2019) – EU Compliant (XRechnung Aligned)

  • Complies with EN 16931 (EU invoicing standard).
  • Uses CII XML, but with new structured tax information.
  • Example:
    <rsm:CrossIndustryInvoice>
        <ram:ExchangedDocument>
            <ram:ID>INV-10001</ram:ID>
            <ram:TypeCode>380</ram:TypeCode> <!-- Invoice Type -->
        </ram:ExchangedDocument>
        <ram:SupplyChainTradeTransaction>
            <ram:ApplicableHeaderTradeSettlement>
                <ram:InvoiceCurrencyCode>EUR</ram:InvoiceCurrencyCode>
            </ram:ApplicableHeaderTradeSettlement>
        </ram:SupplyChainTradeTransaction>
    </rsm:CrossIndustryInvoice>
    

3️⃣ ZUGFeRD 2.1 (2020) – Factur-X & UBL Added

  • Now supports both CII and UBL XML inside the PDF/A-3.
  • Aligns with Factur-X 1.0 (French standard).
  • Example (UBL format):
    <Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
        <cbc:ID>INV-10001</cbc:ID>
        <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
        <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
    </Invoice>
    

4️⃣ ZUGFeRD 2.2 (2022) – Improved PEPPOL Integration

  • Enhancements for PEPPOL BIS Billing 3.0 compatibility.
  • Minor fixes in CII & UBL tax codes.
  • No major structural changes.

5️⃣ ZUGFeRD 2.2.1 (2023) – Refinements

  • Small refinements for better international invoice exchange.
  • Better multi-language support.

πŸ“Œ Summary of Key Differences

Feature ZUGFeRD 1.0 ZUGFeRD 2.0 ZUGFeRD 2.1 (Factur-X 1.0) ZUGFeRD 2.2 / 2.2.1
XML Format CII CII CII + UBL CII + UBL
EU Compliance ❌ No ✅ Yes ✅ Yes ✅ Yes
PEPPOL Support ❌ No ❌ No ⚠️ Partial ✅ Full
XRechnung Alignment ❌ No ✅ Yes ✅ Yes ✅ Yes
France Compatibility (Factur-X) ❌ No ❌ No ✅ Yes ✅ Yes
UBL Support ❌ No ❌ No ✅ Yes ✅ Yes

πŸš€ 

  • ZUGFeRD 1.0: Basic, Germany-only.
  • ZUGFeRD 2.0: Aligned with XRechnung, but CII only.
  • ZUGFeRD 2.1: Supports UBL, same as Factur-X (France).
  • ZUGFeRD 2.2+: Better PEPPOL & global compliance.



1. ZUGFeRD 1.0 (2014)

  • XML Standard: Based on UN/CEFACT CII D16B.
  • Profiles: Basic, Comfort, and Extended.
  • CII Structure:
    • Uses UN/CEFACT’s Cross-Industry Invoice (CII) XML format.
    • Contains standard invoice elements (buyer, seller, invoice lines, tax details).
    • Limited adoption due to lack of alignment with EN 16931 (European Norm).

2. ZUGFeRD 2.0 (2019)

  • XML Standard: Now fully compliant with EN 16931 (EU e-invoicing standard).
  • Profiles: BASIC, EN 16931, EXTENDED.
  • CII Structure Changes:
    • Uses UN/CEFACT CII D16B, but aligned with EN 16931 for better EU compliance.
    • New mandatory fields added for VAT compliance in the EU.
    • Improved handling of invoice corrections and tax codes.
    • Naming conventions updated to match EU specifications.

3. ZUGFeRD 2.1 / Factur-X 1.0 (2020)

  • XML Standard: Still based on UN/CEFACT CII D16B, but introduces Factur-X (French e-invoicing standard).
  • Profiles: MINIMUM, BASIC, BASIC WL (Without Lines), EN 16931, EXTENDED.
  • CII Structure Changes:
    • Factur-X compatibility (France's version of ZUGFeRD).
    • Introduces "BASIC WL" profile (without line-item details).
    • Some elements restructured to match newer business cases.
    • More flexible handling of optional fields for invoices outside the EU.

4. ZUGFeRD 2.2 / Factur-X 1.0.06 (2022)

  • XML Standard: UN/CEFACT CII D16B, still compliant with EN 16931.
  • Profiles: Same as 2.1 (MINIMUM, BASIC, BASIC WL, EN 16931, EXTENDED).
  • CII Structure Changes:
    • Minor refinements and fixes in XML structure for improved validation.
    • Better support for public procurement e-invoices in France and Germany.
    • More structured handling of multi-tax rates and allowances.

5. ZUGFeRD 2.3 / Factur-X 1.0.07 (2024)

  • XML Standard: UN/CEFACT CII D16B, with latest refinements.
  • Profiles: No major changes from ZUGFeRD 2.2.
  • CII Structure Changes:
    • Further refinements for PEPPOL BIS Billing 3.0 compatibility.
    • Updates for French B2B e-invoicing compliance (new legal mandates).
    • Small enhancements for invoice line item details and corrections.

Summary of Differences in CII XML Across ZUGFeRD Versions

Version CII XML Standard Key Changes
ZUGFeRD 1.0 UN/CEFACT CII D16B (basic) Limited adoption, missing EN 16931 alignment.
ZUGFeRD 2.0 UN/CEFACT CII D16B Aligned with EN 16931, improved VAT handling.
ZUGFeRD 2.1 UN/CEFACT CII D16B Introduced Factur-X, new BASIC WL profile.
ZUGFeRD 2.2 UN/CEFACT CII D16B Minor fixes, better tax and procurement handling.
ZUGFeRD 2.3 UN/CEFACT CII D16B PEPPOL BIS 3.0 compatibility, B2B France updates.

 Below are sample XML snippets showing the differences in CII XML across ZUGFeRD versions.


Example: A Simple Invoice Comparison

1️⃣ ZUGFeRD 1.0 (2014) - Basic CII XML

  • Uses UN/CEFACT CII D16B but lacks compliance with EN 16931.
  • No structured VAT details (limited tax category handling).
<CrossIndustryInvoice xmlns="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100">
    <ExchangedDocumentContext>
        <GuidelineSpecifiedDocumentContextParameter>
            <ID>urn:zugferd:1p0:basic</ID>
        </GuidelineSpecifiedDocumentContextParameter>
    </ExchangedDocumentContext>
    <SupplyChainTradeTransaction>
        <ApplicableSupplyChainTradeAgreement>
            <SellerTradeParty>
                <Name>ABC Ltd</Name>
                <PostalTradeAddress>
                    <CityName>Berlin</CityName>
                </PostalTradeAddress>
            </SellerTradeParty>
            <BuyerTradeParty>
                <Name>XYZ GmbH</Name>
            </BuyerTradeParty>
        </ApplicableSupplyChainTradeAgreement>
        <ApplicableSupplyChainTradeSettlement>
            <InvoiceCurrencyCode>EUR</InvoiceCurrencyCode>
            <SpecifiedTradeSettlementMonetarySummation>
                <GrandTotalAmount>1200.00</GrandTotalAmount>
            </SpecifiedTradeSettlementMonetarySummation>
        </ApplicableSupplyChainTradeSettlement>
    </SupplyChainTradeTransaction>
</CrossIndustryInvoice>

πŸ”Ή Key Points:
✔️ Basic invoice structure.
❌ No detailed VAT breakdown.
❌ No compliance with EN 16931.


2️⃣ ZUGFeRD 2.0 (2019) - EN 16931 Compliance

  • Includes tax category codes (required for EU compliance).
  • Uses ZUGFeRD 2.0 profiles (EN 16931, EXTENDED).
<CrossIndustryInvoice xmlns="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100">
    <ExchangedDocumentContext>
        <GuidelineSpecifiedDocumentContextParameter>
            <ID>urn:zugferd:2p0:EN16931</ID>
        </GuidelineSpecifiedDocumentContextParameter>
    </ExchangedDocumentContext>
    <SupplyChainTradeTransaction>
        <ApplicableSupplyChainTradeAgreement>
            <SellerTradeParty>
                <Name>ABC Ltd</Name>
                <PostalTradeAddress>
                    <CityName>Berlin</CityName>
                </PostalTradeAddress>
            </SellerTradeParty>
            <BuyerTradeParty>
                <Name>XYZ GmbH</Name>
            </BuyerTradeParty>
        </ApplicableSupplyChainTradeAgreement>
        <ApplicableSupplyChainTradeSettlement>
            <InvoiceCurrencyCode>EUR</InvoiceCurrencyCode>
            <SpecifiedTradeSettlementMonetarySummation>
                <GrandTotalAmount>1200.00</GrandTotalAmount>
            </SpecifiedTradeSettlementMonetarySummation>
            <ApplicableTradeTax>
                <TypeCode>VAT</TypeCode>
                <CategoryCode>S</CategoryCode>
                <RateApplicablePercent>19</RateApplicablePercent>
                <CalculatedAmount>228.00</CalculatedAmount>
            </ApplicableTradeTax>
        </ApplicableSupplyChainTradeSettlement>
    </SupplyChainTradeTransaction>
</CrossIndustryInvoice>

πŸ”Ή Key Points:
✔️ VAT category code (S for Standard Rate, E for Exempt, etc.).
✔️ Tax calculation details included.
✔️ EN 16931 compliance added.


3️⃣ ZUGFeRD 2.1 / Factur-X 1.0 (2020) - Factur-X Support

  • Supports French Factur-X standard.
  • Introduces BASIC WL (Without Line Items) profile.
  • More structured invoice tax information.
<CrossIndustryInvoice xmlns="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100">
    <ExchangedDocumentContext>
        <GuidelineSpecifiedDocumentContextParameter>
            <ID>urn:factur-x:1p0:EN16931</ID>
        </GuidelineSpecifiedDocumentContextParameter>
    </ExchangedDocumentContext>
    <SupplyChainTradeTransaction>
        <ApplicableSupplyChainTradeAgreement>
            <SellerTradeParty>
                <Name>ABC Ltd</Name>
                <PostalTradeAddress>
                    <CityName>Berlin</CityName>
                </PostalTradeAddress>
            </SellerTradeParty>
            <BuyerTradeParty>
                <Name>XYZ GmbH</Name>
            </BuyerTradeParty>
        </ApplicableSupplyChainTradeAgreement>
        <ApplicableSupplyChainTradeSettlement>
            <InvoiceCurrencyCode>EUR</InvoiceCurrencyCode>
            <ApplicableTradeTax>
                <TypeCode>VAT</TypeCode>
                <CategoryCode>S</CategoryCode>
                <RateApplicablePercent>19</RateApplicablePercent>
                <CalculatedAmount>228.00</CalculatedAmount>
            </ApplicableTradeTax>
            <SpecifiedTradeSettlementMonetarySummation>
                <GrandTotalAmount>1200.00</GrandTotalAmount>
                <TaxBasisTotalAmount>1000.00</TaxBasisTotalAmount>
            </SpecifiedTradeSettlementMonetarySummation>
        </ApplicableSupplyChainTradeSettlement>
    </SupplyChainTradeTransaction>
</CrossIndustryInvoice>

πŸ”Ή Key Points:
✔️ Factur-X ID introduced (urn:factur-x:1p0:EN16931).
✔️ More structured tax details (added TaxBasisTotalAmount).
✔️ More flexible handling for French invoicing laws.


4️⃣ ZUGFeRD 2.3 (2024) - PEPPOL BIS 3.0 Support

  • Improved support for PEPPOL BIS Billing 3.0.
  • Better handling of multi-tax rates.
  • More structured document referencing.
<CrossIndustryInvoice xmlns="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100">
    <ExchangedDocumentContext>
        <GuidelineSpecifiedDocumentContextParameter>
            <ID>urn:zugferd:2p3:PEPPOLBIS</ID>
        </GuidelineSpecifiedDocumentContextParameter>
    </ExchangedDocumentContext>
    <SupplyChainTradeTransaction>
        <ApplicableSupplyChainTradeAgreement>
            <SellerTradeParty>
                <Name>ABC Ltd</Name>
                <PostalTradeAddress>
                    <CityName>Berlin</CityName>
                </PostalTradeAddress>
            </SellerTradeParty>
            <BuyerTradeParty>
                <Name>XYZ GmbH</Name>
            </BuyerTradeParty>
        </ApplicableSupplyChainTradeAgreement>
        <ApplicableSupplyChainTradeSettlement>
            <InvoiceCurrencyCode>EUR</InvoiceCurrencyCode>
            <ApplicableTradeTax>
                <TypeCode>VAT</TypeCode>
                <CategoryCode>S</CategoryCode>
                <RateApplicablePercent>19</RateApplicablePercent>
                <CalculatedAmount>228.00</CalculatedAmount>
            </ApplicableTradeTax>
            <ApplicableTradeTax>
                <TypeCode>VAT</TypeCode>
                <CategoryCode>R</CategoryCode>
                <RateApplicablePercent>7</RateApplicablePercent>
                <CalculatedAmount>70.00</CalculatedAmount>
            </ApplicableTradeTax>
            <SpecifiedTradeSettlementMonetarySummation>
                <GrandTotalAmount>1270.00</GrandTotalAmount>
                <TaxBasisTotalAmount>1000.00</TaxBasisTotalAmount>
            </SpecifiedTradeSettlementMonetarySummation>
            <InvoiceReferencedDocument>
                <IssuerAssignedID>INV-2024-001</IssuerAssignedID>
            </InvoiceReferencedDocument>
        </ApplicableSupplyChainTradeSettlement>
    </SupplyChainTradeTransaction>
</CrossIndustryInvoice>

πŸ”Ή Key Points:
✔️ Support for PEPPOL BIS Billing 3.0.
✔️ Multiple VAT rates (S = 19%, R = 7%).
✔️ Invoice referencing (InvoiceReferencedDocument) for better tracking.


Conclusion

Version Key Differences
ZUGFeRD 1.0 Basic structure, no VAT details.
ZUGFeRD 2.0 Aligned with EN 16931, added VAT tax categories.
ZUGFeRD 2.1 Introduced Factur-X, structured tax handling.
ZUGFeRD 2.3 Supports PEPPOL BIS 3.0, improved multi-tax rates.

  • ZUGFeRD 1.0 had limited adoption due to missing EU compliance.
  • ZUGFeRD 2.x series significantly improved by aligning with EN 16931, making it widely accepted in the EU and France (Factur-X).
  • Each newer version refines XML structures for better compliance, multi-country invoicing, and smoother integration with PEPPOL and public procurement platforms.

Let me know if you need specific XML samples for comparison! πŸš€

Sunday, February 2, 2025

Public and Private Keys in EDI

 

Public and Private Keys in EDI

In Electronic Data Interchange (EDI), public and private keys play a crucial role in securing data transmission, ensuring data integrity, and authenticating trading partners. These keys are primarily used in encryption, decryption, and digital signatures within secure protocols like AS2, SFTP, and HTTPS.

Understanding Public and Private Keys

Public and private keys are part of asymmetric cryptography (Public Key Infrastructure - PKI), where:

  • The public key is shared with anyone and is used for encryption.
  • The private key is kept secret by the owner and is used for decryption or signing.

This key pair ensures secure data exchange between trading partners in EDI.


Use of Public and Private Keys in EDI

1. Encryption & Decryption (Data Security in Transmission)

When sending EDI data over secure channels like AS2 or SFTP, public and private keys are used to encrypt and decrypt the message.

πŸ”Ή Example Scenario:

  • Step 1: The sender (Supplier) encrypts the EDI message (e.g., ANSI X12 850 - Purchase Order) using the recipient's public key.
  • Step 2: The receiver (Retailer) decrypts the EDI message using their own private key.

πŸ”Ή Illustration:
Let’s say Supplier A wants to send an encrypted Purchase Order (850) to Retailer B securely over AS2.

  1. Supplier A encrypts the 850 message with Retailer B’s public key.
  2. The encrypted file is transmitted over AS2.
  3. Retailer B decrypts it using their private key and reads the order.

This process ensures that even if someone intercepts the message, they cannot read it without Retailer B’s private key.


2. Digital Signatures (Authentication & Data Integrity)

In EDI, digital signatures confirm the authenticity of the sender and ensure the message has not been altered.

πŸ”Ή Example Scenario:

  • Step 1: The sender (Supplier) digitally signs the EDI file using their private key before sending it.
  • Step 2: The receiver (Retailer) verifies the signature using the sender’s public key.

πŸ”Ή Illustration:

  1. Supplier A generates a digital signature using their private key and attaches it to the 850 Purchase Order.
  2. Retailer B receives the signed message and verifies the signature using Supplier A’s public key.
  3. If the verification fails, it means the message was tampered with or came from an unauthorized sender.

This prevents message tampering and fraud in EDI transactions.


3. Secure Protocols in EDI using Public/Private Keys

EDI transactions use secure communication protocols that implement public-private key encryption, such as:
AS2 (Applicability Statement 2) – Uses public-private key pair for encryption and digital signatures to ensure data security.
SFTP (Secure File Transfer Protocol) – Uses SSH keys (public/private pair) to authenticate trading partners securely.
HTTPS (Hypertext Transfer Protocol Secure) – Uses SSL/TLS certificates with public-private keys to encrypt data transmission.

πŸ”Ή Example: AS2 Communication Flow

  1. Encryption: Sender encrypts the message using the recipient’s public key.
  2. Signing: Sender signs the message with their private key.
  3. Transmission: The encrypted and signed message is sent over AS2.
  4. Verification: Receiver verifies the signature using the sender’s public key.
  5. Decryption: Receiver decrypts the message using their private key.

This ensures secure and authenticated message exchange in B2B EDI transactions.



Public and private keys are essential for securing EDI transactions, ensuring data confidentiality, authentication, and integrity. They are widely used in secure EDI protocols like AS2, SFTP, and HTTPS to encrypt messages and verify sender identities.

Generating and Using Public-Private Keys in AS2 & SFTP for EDI

Here we will walk you through how to generate and use public-private keys in AS2 and SFTP for secure EDI transactions.


1. Using Public-Private Keys in AS2 for EDI

Step 1: Generate a Public-Private Key Pair (SSL Certificate)

AS2 relies on X.509 certificates for encryption and digital signatures. These certificates contain public-private key pairs. You can generate them using OpenSSL.

Generating a Self-Signed Certificate (Public-Private Key Pair)

Run the following command in your terminal or command prompt:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout private.key -out public.crt
  • private.key → Your private key (kept secret).
  • public.crt → Your public certificate (shared with trading partners).

πŸ’‘ If using a third-party CA (Certificate Authority), you’ll need to generate a CSR (Certificate Signing Request) and get a signed certificate.


Step 2: Configure AS2 in EDI Software

Once the key pair is generated, configure it in your EDI/AS2 software (e.g., IBM Sterling Integrator,OpenText TradingGrid, Cleo, BizTalk, Seeburger, Axway, etc.).

For the Sender (Supplier):

  • Encryption: Use the receiver’s public key (from their .crt file).
  • Signing: Use your private key to sign outgoing messages.

For the Receiver (Retailer):

  • Decryption: Use your private key to decrypt messages.
  • Signature Verification: Use the sender’s public key to verify signatures.

Step 3: AS2 EDI Transmission Process

  1. Supplier (Sender) encrypts the EDI 850 Purchase Order using the retailer’s public key.
  2. Supplier signs the document with their private key.
  3. Supplier sends the AS2 message to the retailer’s AS2 endpoint.
  4. Retailer decrypts the AS2 message using their private key.
  5. Retailer verifies the sender’s signature using the supplier’s public key.
  6. Retailer sends back an MDN (Message Disposition Notification), signed with their private key, which the supplier verifies.

πŸ”Ή MDN (Message Disposition Notification) confirms successful receipt and integrity of the file.

If MDN verification fails → The message was tampered with or sent from an unauthorized source.


2. Using Public-Private Keys in SFTP for EDI

SFTP (Secure File Transfer Protocol) uses SSH key pairs instead of SSL certificates.

Step 1: Generate SSH Key Pair

On your local machine, run:

ssh-keygen -t rsa -b 2048 -f my_sftp_key
  • my_sftp_key → Your private key (kept secret).
  • my_sftp_key.pub → Your public key (shared with trading partners).

Step 2: Configure SFTP Authentication

  1. Send the my_sftp_key.pub file to your trading partner.
  2. The partner adds the public key to their SFTP server’s authorized_keys file:
    cat my_sftp_key.pub >> ~/.ssh/authorized_keys
    
  3. When connecting, use the private key for authentication:
    sftp -i my_sftp_key user@sftpserver.com
    
    ✅ No password is needed, and authentication is secure.

Step 3: Secure File Transfer in EDI

πŸ”Ή Example: Sending an EDI 810 Invoice via SFTP

  1. Encrypt the file (optional, using OpenSSL):
    openssl smime -encrypt -aes-256-cbc -in invoice_810.edi -out invoice_810.enc -outform DER partner_public.crt
    
  2. Transfer the encrypted file using SFTP:
    sftp -i my_sftp_key user@sftpserver.com <<EOF
    put invoice_810.enc
    bye
    EOF
    
  3. The receiver decrypts the file using their private key:
    openssl smime -decrypt -in invoice_810.enc -out invoice_810.edi -inform DER -inkey private.key
    

  • AS2 (EDI over HTTP): Uses public-private key pairs (X.509 certificates) for encryption & signing.
  • SFTP (EDI over SSH): Uses public-private key pairs (SSH keys) for authentication.

Both methods ensure security, integrity, and authentication in EDI transactions. πŸš€

Real-World Example: AS2 EDI Message Exchange with Public-Private Keys

This example will demonstrate how to encrypt, sign, and send an EDI file over AS2 using OpenSSL and Python. It includes:
Generating Keys & Certificates
Encrypting & Signing an EDI 850 Purchase Order
Sending via AS2
Receiving, Decrypting, and Verifying the Signature


Step 1: Generate Public-Private Key Pairs

Each trading partner (Supplier & Retailer) needs their own key pair.

Run these commands to generate keys:

For Supplier (Sender)

# Generate private key
openssl genrsa -out supplier_private.key 2048

# Generate public certificate
openssl req -new -x509 -key supplier_private.key -out supplier_public.crt -days 365

For Retailer (Receiver)

# Generate private key
openssl genrsa -out retailer_private.key 2048

# Generate public certificate
openssl req -new -x509 -key retailer_private.key -out retailer_public.crt -days 365

Step 2: Encrypt & Sign the EDI Message

Let’s say the Supplier wants to send an EDI 850 Purchase Order securely to the Retailer.

Sample EDI 850 File (purchase_order.edi)

ISA*00*          *00*          *ZZ*SENDERID       *ZZ*RECEIVERID     *230201*1234*U*00401*000000001*0*T*>
GS*PO*SENDERID*RECEIVERID*20230201*1234*1*X*004010
ST*850*0001
BEG*00*NE*123456**20230201
N1*ST*Retailer Name*92*12345
PO1*1*10*EA*25.00*PE*XYZ123
CTT*1
SE*6*0001
GE*1*1
IEA*1*000000001

Encrypt the EDI File with Receiver’s Public Key

openssl smime -encrypt -aes-256-cbc -in purchase_order.edi -out encrypted_edi.dat -outform DER retailer_public.crt

Sign the Encrypted File with Supplier’s Private Key

openssl smime -sign -in encrypted_edi.dat -out signed_edi.dat -signer supplier_public.crt -inkey supplier_private.key -nodetach -outform DER

At this point, the signed and encrypted file (signed_edi.dat) is ready for secure AS2 transmission.


Step 3: Sending the AS2 Message

We will use Python to send the AS2 message via an AS2 server.

Python Code to Send AS2 Message

import requests

# Define AS2 parameters
as2_url = "https://as2.receiver.com/receive"  # Retailer AS2 server
headers = {
    "AS2-To": "RetailerAS2ID",
    "AS2-From": "SupplierAS2ID",
    "Content-Type": "application/pkcs7-mime",
    "EDIINT-Features": "multiple-attachments",
}

# Load the signed EDI file
with open("signed_edi.dat", "rb") as file:
    edi_data = file.read()

# Send AS2 request
response = requests.post(as2_url, headers=headers, data=edi_data)

# Print response
print(f"Response Code: {response.status_code}")
print(f"MDN Response: {response.text}")

If successful, the retailer will return an MDN (Message Disposition Notification) confirming receipt.


Step 4: Receiving & Verifying the AS2 Message

At the Retailer’s AS2 server, the received message must be:

  1. Verified for authenticity using the sender’s public key.
  2. Decrypted using the receiver’s private key.

Verify the Digital Signature

openssl smime -verify -in signed_edi.dat -CAfile supplier_public.crt -out verified_edi.dat

If successful, the file is verified as authentic.

Decrypt the Verified EDI File

openssl smime -decrypt -in verified_edi.dat -inform DER -inkey retailer_private.key -out decrypted_edi.edi

Now the EDI 850 Purchase Order is readable and can be processed!


Step 5: Sending MDN Response

After successful verification and decryption, the Retailer sends an MDN response back to the Supplier.

Example MDN Message (mdn_response.txt):

AS2-To: SupplierAS2ID
AS2-From: RetailerAS2ID
Disposition: automatic-action/MDN-sent-automatically; processed
Original-Message-ID: <123456@example.com>

Digitally Sign the MDN with the Retailer’s Private Key

openssl smime -sign -in mdn_response.txt -out signed_mdn.dat -signer retailer_public.crt -inkey retailer_private.key -nodetach -outform DER

Send MDN via AS2

import requests

# AS2 Endpoint of Supplier
as2_supplier_url = "https://as2.supplier.com/receive_mdn"

# Load Signed MDN
with open("signed_mdn.dat", "rb") as file:
    mdn_data = file.read()

# Send MDN
response = requests.post(as2_supplier_url, headers={"Content-Type": "application/pkcs7-mime"}, data=mdn_data)

print(f"MDN Sent. Response Code: {response.status_code}")

If the Supplier receives and verifies the MDN, the transaction is complete!


Summary of AS2 Secure Exchange Process

1️⃣ Supplier encrypts the EDI file with Retailer’s public key.
2️⃣ Supplier signs the encrypted file with their private key.
3️⃣ Supplier sends the AS2 message to the Retailer.
4️⃣ Retailer verifies the signature using Supplier’s public key.
5️⃣ Retailer decrypts the file using their private key.
6️⃣ Retailer sends a signed MDN response back to the Supplier.
7️⃣ Supplier verifies the MDN signature, confirming receipt.



πŸ”Ή This real-world AS2 example shows how public-private keys are used for encryption, signing, and verification in EDI transactions.
πŸ”Ή It ensures data integrity, security, and non-repudiation in B2B communications.

AS2 EDI Message Exchange Example Using Mendelson AS2 & Cleo

This guide covers how to set up an AS2 connection, configure certificates, and exchange EDI messages securely using Mendelson AS2 and Cleo Integration Cloud.


1. Setting Up AS2 in Mendelson AS2

Mendelson AS2 is an open-source AS2 server used for testing and real-world EDI AS2 transactions.

Step 1: Install Mendelson AS2

  1. Download Mendelson AS2 from:
    πŸ”— https://www.mendelson-e-c.com/AS2
  2. Install and run it.

Step 2: Generate Public-Private Keys in Mendelson

Mendelson AS2 allows you to generate X.509 certificates for encryption and signing.

Generate Key Pair (Certificate)

  1. Go to Certificates → Generate new key.
  2. Enter details (Company Name, Validity, Algorithm = RSA 2048).
  3. Export:
    • Public Certificate (.cer) → Share with Trading Partner.
    • Private Key (.p12 or .keystore) → Keep secure.

Import Trading Partner’s Public Key

  1. Ask your Trading Partner (e.g., Cleo Integration Cloud) for their public certificate.
  2. In Mendelson, go to Certificates → Import public certificate.
  3. Browse and import the .cer file.

Step 3: Configure AS2 Trading Partner

  1. Add Trading Partner (Cleo or any AS2 endpoint).

    • AS2 ID: CleoAS2
    • AS2 URL: https://cleoas2.com/receive
    • Public Key: Use Cleo’s .cer file.
    • Private Key: Use your private key for signing.
  2. Configure MDN Settings

    • Request MDN (Signed) to get confirmation of message receipt.

Step 4: Sending an EDI File from Mendelson

  1. Prepare an EDI 850 Purchase Order file (purchase_order.edi).
  2. Go to Mendelson AS2 → Send File.
  3. Select the Trading Partner (Cleo).
  4. Choose the EDI file and click Send.
  5. Monitor the Log Tab to check transmission status.

If successful, Cleo will send an MDN receipt confirming delivery.


2. Setting Up AS2 in Cleo Integration Cloud

Cleo Integration Cloud (CIC) is a cloud-based AS2 solution for B2B/EDI transactions.

Step 1: Configure Cleo AS2 Partner

  1. Log in to Cleo Integration Cloud.
  2. Navigate to Partners → Add AS2 Partner.
  3. Enter Partner Details:
    • AS2 ID: MendelsonAS2
    • AS2 URL: http://mendelsonserver.com:4080/as2/HttpReceiver
    • Public Certificate: Upload Mendelson’s .cer file.

Step 2: Sending an EDI File from Cleo

  1. Go to Cleo Integration Cloud → Transactions.
  2. Select Send New AS2 Message.
  3. Choose the Trading Partner (Mendelson).
  4. Upload the EDI File (purchase_order.edi).
  5. Click Send.

Mendelson will receive the AS2 message and send an MDN in response.


Step 3: Verify MDN (Message Disposition Notification)

After the message is received:

  • Mendelson logs show "MDN Received Successfully."
  • Cleo logs confirm the message was decrypted and processed.

3. Debugging AS2 Issues

πŸ’‘ Common AS2 Issues & Fixes

Issue Possible Cause Fix
AS2 Connection Failed Wrong URL Verify AS2 endpoint URL
Signature Verification Failed Wrong public certificate Re-import correct .cer file
Encryption Failed No matching private key Use correct .p12 keystore


✅ Mendelson AS2 & Cleo Integration Cloud allow secure AS2 EDI transactions using public-private keys.
✅ This setup ensures encryption, authentication, and MDN confirmations in B2B EDI.

I can guide you through a step-by-step Mendelson & Cleo AS2 setup with logs and screenshots. Since I can't generate actual screenshots, I'll provide detailed instructions so you can follow along easily.


Step-by-Step AS2 Setup: Mendelson AS2 & Cleo Integration Cloud

πŸ”Ή Step 1: Install & Configure Mendelson AS2

1.1 Install Mendelson AS2

1️⃣ Download Mendelson AS2 from:
πŸ”— https://www.mendelson-e-c.com/AS2
2️⃣ Extract and run startserver.bat (Windows) or startserver.sh (Linux).
3️⃣ Open Mendelson AS2 GUI (http://localhost:4080) in your browser.


1.2 Generate Public-Private Keys in Mendelson

πŸ”Ή Go to: Certificates → Generate new key
1️⃣ Enter:

  • Company Name: MendelsonAS2
  • Algorithm: RSA 2048
  • Validity: 365 Days
    2️⃣ Click Generate and Export:
  • Public Certificate (mendelson_public.cer) → Share with Cleo.
  • Private Key (mendelson_private.p12) → Keep safe.

1.3 Import Cleo's Public Key into Mendelson

πŸ”Ή Go to: Certificates → Import Public Certificate
1️⃣ Browse and select Cleo’s .cer file.
2️⃣ Click Import.


1.4 Add Cleo as a Trading Partner in Mendelson

πŸ”Ή Go to: Configuration → Partner Management
1️⃣ Click Add New Partner

  • AS2 ID: CleoAS2
  • AS2 URL: https://cleoas2.com/receive
  • Public Certificate: Select Cleo’s imported certificate.
  • Private Key: Use Mendelson’s private key for signing.
    2️⃣ Click Save.

πŸ”Ή Step 2: Configure Cleo Integration Cloud (CIC AS2)

2.1 Add Mendelson as an AS2 Partner in Cleo

πŸ”Ή Go to: Cleo Integration Cloud → Partners
1️⃣ Click Add Partner → AS2 Partner
2️⃣ Enter:

  • Partner Name: Mendelson
  • AS2 ID: MendelsonAS2
  • AS2 URL: http://mendelsonserver.com:4080/as2/HttpReceiver
    3️⃣ Upload Mendelson’s .cer file.
    4️⃣ Click Save.

πŸ”Ή Step 3: Send an EDI File via AS2

3.1 Sending an EDI 850 Purchase Order from Mendelson

πŸ”Ή Go to: Transactions → Send File
1️⃣ Select the Trading Partner (Cleo).
2️⃣ Upload EDI 850 File (purchase_order.edi).
3️⃣ Click Send.
4️⃣ Monitor Logs:

  • AS2 Message Sent Successfully.
  • MDN Received from Cleo.

3.2 Sending an EDI 810 Invoice from Cleo to Mendelson

πŸ”Ή Go to: Cleo Integration Cloud → Transactions → Send AS2 Message
1️⃣ Select the Trading Partner (Mendelson).
2️⃣ Upload EDI 810 File (invoice_810.edi).
3️⃣ Click Send.
4️⃣ Monitor Cleo Logs:

  • AS2 Message Sent Successfully.
  • MDN Received from Mendelson.

πŸ”Ή Step 4: Verify AS2 Transactions

4.1 Checking AS2 Logs in Mendelson

πŸ”Ή Go to: Logs → Transaction Log
✅ Look for:

  • Sent Message → 200 OK (if successful)
  • MDN Received → Signature Verified

4.2 Checking AS2 Logs in Cleo

πŸ”Ή Go to: Cleo Integration Cloud → Logs
✅ Look for:

  • Received AS2 Message → Decryption Successful
  • MDN Sent to Mendelson

πŸ› ️ Troubleshooting AS2 Issues

Issue Possible Cause Fix
AS2 Connection Failed Wrong URL Verify AS2 endpoint URL
Signature Verification Failed Wrong public certificate Re-import correct .cer file
Encryption Failed No matching private key Use correct .p12 keystore

πŸš€ Final Outcome

Mendelson ↔ Cleo AS2 communication is successfully established!
EDI files are securely transmitted, encrypted, signed, and acknowledged with MDNs!