zugferd: the future of invoicing with pdf

The future of InvoicingPDF Technical Conference 2015, San Jose (CA)

The Future of Invoicing2

Why this talk2015: 42+ billion E-Bills/E-Invoices worldwide

Brazil: > 90%Mexico: > 75%Europe: about 28% (North: > 40%)Study for a handful of European countries: 75% e-Invoices are PDF

Australia: 50 competing solutionsAfter several years: only up to 10% adoption rate of eInvoices

Europe: 10,000 ERP / Accounting systems:But can they talk to each other?

Directive 2014/55/EU100,000 agencies and administration need to use “a certain standard” by the end of 2018No PDF/R allowed, but either XML or PDF + XML45% - 65% of businesses are suppliers to the public sector

Agenda

• Portable Document Format (PDF): focus on PDF/A and PDF/UA• Electronic Data Interchange (EDI): focus on XML standards• ZUGFeRD: builds on top of the PDF/A-3 and the CII standard

The Portable Document Format (PDF)

An “umbrella” of StandardsPDF/A: Long-term preservationPDF/UA: Universal Accessibility

PDF: an umbrella of standardsPDFPortable Document FormatFirst released by Adobe in 1993ISO Standard since 2008ISO 32000

PDF/Eengineering

Since 2008

ISO 24517

PDF/VTprinting

Since 2010

ISO 16612

PDF/Xgraphic arts

Since 2001

ISO 15930

PDF/Aarchive

Since 2005

ISO 19005

PDF/UAaccessibility

Since 2012

ISO 14289

Related:• XFDF (ISO)• EcmaScript (ISO)• PRC (ISO)• PAdES (ETSI)

Focus on PDF/AISO-19005

Long-term preservation of documentsApproved parts will never become invalidIndividual parts define new, useful features

Obligations and restrictionsMetadata: ISO 16684, eXtensible Metadata Platform (XMP)The document must be self-contained: All fonts need to be embedded No external movie, sound or other binary filesNo JavaScript allowedNo encryption allowed

Three standardsPDF/A-1 (2005)

based on PDF 1.4Level B (“basic”): visual appearanceLevel A (“accessible”): visual appearance + structural and semantic properties (Tagged PDF)

PDF/A-2 (2011)Based on ISO-32000-1Features introduced in PDF 1.5, 1.6, and 1.7: Added support for JPEG2000, Collections, object-level XMP, optional content Improved support for transparency, comment types and annotations, digital signaturesLevel U (“unicode”): visual appearance + all text is in Unicode

PDF/A-3 (2012)Based on PDF/A-2 with only 1 difference: attachments do not need to be PDF/A

PDF is a binary format

XMP metadata in plain text

Fonts are embedded

Verify comformity…

There’s more!

Focus on PDF/UAISO 14289 (2012): AccessibilityImportant in the context of Section 508Requirements:

Tagged PDF Complete tagging of “real content” in logical reading order Tags must correctly represent the document’s semantic structures Other content is marked as “artifact”Problematic content is prohibited (e.g. undesired color contrasts)Graphics must include alternative text descriptionsFonts must be embedded and text mapped to UNICODE

PDF/UA complements WCAG 2.0PDF/UA is compatible with PDF/A

Accessible PDF?

Structure and semantics

list item

Label Content

How to read this chart?

Structure of the data

Person 2 1.7 1.4 1.3 1.9 2.1 0.8 2.2 1.8 1.6 1 1.4

Position 3 2.3 2 1.8 3.2 3.9 2.1 3.1 3.2 2.3 2 2.1

ributi

Resolve

abbreviations

What goes into

rows / columns?

Make info color

independent

Structure of the dataPerson Position

Functional Leadership 2 3

Risk Management 1.7 2.3

Structured Finance 1.4 2

Mergers & Acquisitions 1.3 1.8

Governance & Internal Control 1.9 3.2

Accounting Operations 2.1 3.9

Treasury Operations 0.8 2.1

Management Information & Business Decision Support 2.2 3.1

Business Planning & Strategy 1.8 3.2

Finance Contribution to IT Managemen 1.6 2.3

Commencial Activities 1 2

Taxation 1.4 2.1

Applied to invoices

PDF/UA: verification?

PDF for invoices?Yes, because humans like PDF:

PDF Viewers are ubiquitousPDF is already the most widely used format for exchanging documentsPDFs are easy to copy, share, file,…PDF/A ensures long-term preservation: the visual representation remains identicalPDF/UA makes invoices accessible to all

No, because machines struggle with PDF:Parsing PDF isn’t trivial (and not all business software is PDF-aware)Not all PDFs are digitally born (scanned pages; OCR)Tagged PDF isn’t well-suited to store the semantics of an invoiceHumans want human language (“English”); machines need encoded data (“en-US”)

Electronic Data Interchange (EDI)

electronic business XML (ebXML)Uniform Business Language (UBL)Core Components Library (CCL)Cross Industry Invoice (CCI)

EDIRequires:

bilateral agreementsSoftware that Shapes the data the way the receiver expects itParses the data following the rules the sender used to provided it

Cost is only justifiable for large corporations with a large volume of invoices

How to reduce this cost? Introduce and use standards!

Electronic Business XML (ebXML)1999: Electronic Business XML initiative

United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT)Organization for the Advancement of Structured Information Standards (OASIS)

2004: ISO 15000Part 1: ebXML Collaborative Profile AgreementPart 2: ebXML Messaging Service SpecificationPart 3: ebXML Registry Information ModelPart 4: ebXML Registry Services Specification

Part 5: building blocks representing general types of dataISO 15000-5:2005: ebXML Core Components Technical Specification (CCTS)ISO 15000-5:2014: ebXML Core Components Specification (CCS)

Universal Business Language (UBL)Developed by OASIS in full conformance with CCTSFoundation for successful international frameworks such as ePrior, PEPPOL,…An XML-only specificationData model isn’t normative

Core Components Library (CCL)UN/CEFACT released several versions of a Core Components LibraryAlso based on ISO 15000-5:2005CCL = repository of easily reused business data components

Templates describing a postal address, tax information, payment information,…Syntax-independent (other formats than XML are possible)Resulted in ISO 15000-5:2014 (normative)

Cross Industry Invoice (CCI)UN/CEFACT:

Used CCS and CCL to create specific business document models: Cross Industry Order: CIO Cross Industry Order Response: CIOR Cross Industry Invoice: CIIAll models are syntax-independent (common language; mutual agreements on format)

European Committee for Standardisation (CEN):Created different Message User Guides (MUG)E.g. the Core Invoice Data Model MUG, derived from the CII standardCEN Workgroup Agreements about 100 field types related to invoices: CWA 16356-1: setup CWA 16356-2: content CWA 16356-3: data structures

ZUGFeRD: PDF/A + CII

A single invoiceFor humansFor machines

ZUGFeRD: closing the gapZentraler User Guide des Forums elektronische Rechnung Deutschland (June 2014)

Developed by FeRD (Forum elektronische Rechnung Deutschland) founded in March 2010Based on PDF/A-3: Archiving + AttachmentImposes an XML schema based on CII

Goal: electronically exchange invoicesReduce invoicing costOptimize processing costFor humans as well as for machinesFor SMEs as well as big corporations

ZUGFeRD profiles

BASICData fields (structured data)Free text fields

COMFORTData fields (structured data)Free text fieldsQualified free text fields (Tagged information)

EXTENDEDAll of the above and more…

Basic profile: free text

Comfort profile: qualified text

Basic profile: line items

Comfort profile: line items

XML in ZUGFeRDRequirements ISO 15000-5:2014 Core Component Specification

Definition of semantic requirements

Semantics

UN/CCL 13BUNECE Core Components LibrarySemantic component library (e.g. buyer)Including the definition of used codes

CCBDA 1.0 UN/CEFACT Core Components Business Document Assembly:Set of rules on how to build a semantic message data modelZUGFeRD data model:Applying cross industry invoice and MUG rule setfor profiling (CEN CWA MUG)

ZUGFeRD DM

SyntaxNDR 2.1 Naming and Design Rules:

Set of rules to create an XML schema out of the data model

ZUGFeRD schema:• A single schema for Extended, Comfort and Basic• Code lists are published separately

ZUGFeRD schema

PDF/A-3 and ZUGFeRDSpecific XMP extension schema for ZUGFeRD with identification of profilePDF/A-3 gives visual representation of invoice that is human-readable

Level of conformance doesn’t matterInvoice data is imbedded as XML in the PDF/A file: 1 document = 1 invoice

Name of the file must be “ZUGFeRD-invoice.xml”Mime-type text/xml; encoding UTF-8Relationship: “Alternative”Params must at least contain a ModDateOther attachments (e.g. “Data”) are allowed

BenefitsSave costs on printing, envelopes and postageNo need to copy, scan, OCR invoices (less errors)Approval process can be done digitally (*)Faster processing = faster payment?No need to file invoices as paper documentsDifferent software systems only need to understand a single format (choice!)SMEs can meet requirements of large corporations without former agreementMails with ZUGFeRD attachment could be detected and filed automaticallyBanks could read ZUGFeRD invoices and process them immediately…

zugferd: the future of invoicing with pdf

Software

zugferd: an overview

government invoicing (g-invoicing)government invoicing...

customer invoicing

better invoicing

e-invoicing is easy invoicing: 5 benefits of going...

electronic invoicing in denmark -...

tieto the future of e-invoicing

the future of invoicing

inter company invoicing

bmw e-invoicing · 2020-03-12 · - 3 - beside invoice cii...

the future of e-invoicing, или Будущее...

invoicing estimates

zugferd e-invoicing in germany based on european standards...

the zugferd format - konik · 2020. 10. 23. · 1 the...

honora investments ltd tnt caricom export invoicing...

electronic invoicing & payment

e- invoicing - vatsintech · 2020. 3. 8. · e-invoicing...

supplier invoicing

world map of e-invoicing - purchasing...

electronic invoicing (e-invoicing) - pwc · pdf fileand...