Download pdf - The Future of Invoicing

© 2015, iText Group NV, iText Software Corp., iText Software BVBA© 2015, iText Group NV, iText Software Corp., iText Software BVBA

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

© 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

© 2015, iText Group NV, iText Software Corp., iText Software BVBA

The Future of Invoicing3

The Portable Document Format (PDF)

An “umbrella” of Standards

PDF/A: Long-term preservation

PDF/UA: Universal Accessibility


PDF: an umbrella of standards


PDFPortable Document FormatFirst released by Adobe in 1993ISO Standard since 2008

ISO 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/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 comformance…



There’s more!



Focus on PDF/UAISO 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

Ris

k M

anag

em

en

t

Stru

ctu

red

Fin

ance

Me

rge

rs &

acq

uis

itio

ns

Go

vern

ance

& In

tern

al C

on

tro

l

Acc

ou

nti

ng

Op

era

tio

ns

Tre

asu

ry o

pe

rati

on

s

Man

age

me

nt

Info

rmat

ion

&

Bu

sin

ess

De

cisi

on

Su

pp

ort

Bu

sin

ess

Pla

nn

ing

& S

trat

egy

Fin

ance

Co

ntr

ibu

tio

n t

o IT

M

anag

em

en

t

Co

mm

erc

ial A

ctiv

itie

s

Taxa

tio

n

Fun

ctio

nal

Le

ade

rsh

ip


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

For humans and machines

Digital Signatures

PAdES


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:2014Core Component SpecificationDefinition 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

Syntax

NDR 2.1Naming 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

…




Questions?

Bruno Lowagie

[email protected]

iText Software Corp.: +1 617 982 2646