ZUGFeRD: The future of invoicing with PDF

© 2015, iText Group NV, iText Software Corp., iText Software BVBA© 2015, iText Group NV, iText Software Corp., iText Software BVBA
The future of Invoicing
PDF Technical Conference 2015, San Jose (CA)

© 2015, iText Group NV, iText Software Corp., iText Software BVBA
Why this talk
2015: 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 solutions
After 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/EU
100,000 agencies and administration need to use “a certain standard” by the end of 2018
No PDF/R allowed, but either XML or PDF + XML
45% - 65% of businesses are suppliers to the public sector
The Future of Invoicing2

© 2015, iText Group NV, iText Software Corp., iText Software BVBA© 2015, iText Group NV, iText Software Corp., iText Software BVBA
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 Standards
PDF/A: Long-term preservation
PDF/UA: Universal Accessibility

PDF: an umbrella of standards
PDF
Portable Document Format
First released by Adobe in 1993
ISO Standard since 2008
ISO 32000
PDF/E
engineering
Since 2008
ISO 24517
PDF/VT
printing
Since 2010
ISO 16612
PDF/X
graphic arts
Since 2001
ISO 15930
PDF/A
archive
Since 2005
ISO 19005
PDF/UA
accessibility
Since 2012
ISO 14289
Related:
• XFDF (ISO)
• EcmaScript (ISO)
• PRC (ISO)
• PAdES (ETSI)

Focus on PDF/A
ISO-19005
Long-term preservation of documents
Approved parts will never become invalid
Individual parts define new, useful features
Obligations and restrictions
Metadata: 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 files
No JavaScript allowed
No encryption allowed

Three standards
PDF/A-1 (2005)
based on PDF 1.4
Level B (“basic”): visual appearance
Level A (“accessible”): visual appearance + structural and semantic properties (Tagged PDF)
PDF/A-2 (2011)
Based on ISO-32000-1
Features 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 signatures
Level 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/UA
ISO 14289 (2012): Accessibility
Important in the context of Section 508
Requirements:
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 descriptions
Fonts must be embedded and text mapped to UNICODE
PDF/UA complements WCAG 2.0
PDF/UA is compatible with PDF/A

Accessible PDF?

Structure and semantics
title
list item
list item
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
RiskManagement
StructuredFinance
Mergers&acquisitions
Governance&InternalControl
AccountingOperations
Treasuryoperations
ManagementInformation&
BusinessDecisionSupport
BusinessPlanning&Strategy
FinanceContributiontoIT
Management
CommercialActivities
Taxation
FunctionalLeadership

Structure of the data
Person 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 ubiquitous
PDF is already the most widely used format for exchanging documents
PDFs are easy to copy, share, file,…
PDF/A ensures long-term preservation: the visual representation remains identical
PDF/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 invoice
Humans 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)

EDI
Requires:
bilateral agreements
Software that
Shapes the data the way the receiver expects it
Parses 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 15000
Part 1: ebXML Collaborative Profile Agreement
Part 2: ebXML Messaging Service Specification
Part 3: ebXML Registry Information Model
Part 4: ebXML Registry Services Specification
Part 5: building blocks representing general types of data
ISO 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 CCTS
Foundation for successful international frameworks such as ePrior, PEPPOL,…
An XML-only specification
Data model isn’t normative

Core Components Library (CCL)
UN/CEFACT released several versions of a Core Components Library
Also based on ISO 15000-5:2005
CCL = 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: CII
All 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 standard
CEN 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 invoice
For humans
For machines

ZUGFeRD: closing the gap
Zentraler User Guide des Forums elektronische Rechnung Deutschland (June 2014)
Developed by FeRD (Forum elektronische Rechnung Deutschland) founded in March 2010
Based on PDF/A-3: Archiving + Attachment
Imposes an XML schema based on CII
Goal: electronically exchange invoices
Reduce invoicing cost
Optimize processing cost
For humans as well as for machines
For SMEs as well as big corporations

ZUGFeRD profiles
BASIC
Data fields (structured data)
Free text fields
COMFORT
Data fields (structured data)
Free text fields
Qualified free text fields (Tagged information)
EXTENDED
All of the above and more…

Basic profile: free text

Comfort profile: qualified text

Basic profile: line items

Comfort profile: line items

XML in ZUGFeRD
Requirements ISO 15000-5:2014
Core Component Specification
Definition of semantic requirements
Semantics
UN/CCL 13B
UNECE Core Components Library
Semantic 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 model
ZUGFeRD data model:
Applying cross industry invoice and MUG rule set
for profiling (CEN CWA MUG)
ZUGFeRD DM
Syntax
NDR 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 ZUGFeRD
Specific XMP extension schema for ZUGFeRD with identification of profile
PDF/A-3 gives visual representation of invoice that is human-readable
Level of conformance doesn’t matter
Invoice 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-8
Relationship: “Alternative”
Params must at least contain a ModDate
Other attachments (e.g. “Data”) are allowed

Benefits
Save costs on printing, envelopes and postage
No 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 documents
Different software systems only need to understand a single format (choice!)
SMEs can meet requirements of large corporations without former agreement
Mails with ZUGFeRD attachment could be detected and filed automatically
Banks could read ZUGFeRD invoices and process them immediately
…

ZUGFeRD: The future of invoicing with PDF

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (6)

Plus de iText Group nv

Plus de iText Group nv (12)

Dernier

Dernier (20)

ZUGFeRD: The future of invoicing with PDF