(1)1
OpenPEPPOL Position Paper
on the European Commission proposal for a Directive on electronic
invoicing in public procurement
Brussels,
11
October
2013
OpenPEPPOL
AISBL
‐
Rond‐point
Schuman
6
‐
1040
Brussels,
Belgium
www.peppol.eu
‐
[email protected]
2
OpenPEPPOL opinion on the proposal for a Directive on electronic
invoicing in public procurement
Introduction
OpenPEPPOL
welcomes
the
European
Commission’s
proposal
for
a
Directive
on
electronic
invoicing
in
public
procurement1
,
and
the
focus
on
shifting
towards
a
paperless
public
administration,
particularly
its
cross‐border
dimension.
The
mission
of
the
PEPPOL
(Pan‐European
Public
Procurement
Online)
project
and
now
of
its
successor,
OpenPEPPOL,
is
specifically
to
enable
cross‐border
interoperability
of
electronic
public
procurement,
promoting
the
use
of
its
standards
based
specifications
across
Europe.
OpenPEPPOL
strongly
supports
the
objective
of
the
Directive
to
remove
market
access
barriers
in
cross‐
border
public
procurement,
in
order
to
improve
the
conditions
for
the
functioning
of
the
internal
market.
Summary of the OpenPEPPOL position
1‐ The
Directive
should
acknowledge,
in
its
preamble,
the
efforts
made
by
the
EC
co‐funded
Large
Scale
Pilot
PEPPOL
(Pan‐European
Public
Procurement
Online)
to
facilitate
cross
border
e‐invoicing
in
public
procurement.
In
particular,
the
results
achieved
through
use
of
the
PEPPOL
Business
Interoperability
Specifications
(BIS),
its
network2
ensuring
secure
and
reliable
transmission
of
e‐
invoices
and
other
business
documents
between
trading
partners,
as
well
as
the
legal
framework3
,
established
to
facilitate
seamless
many‐to‐many
interoperability,
should
be
recognised
as
the
platform
for
the
further
development
of
end‐to‐end
e‐procurement
in
the
public
sector
in
Europe.
The
PEPPOL
BIS
implements
the
results
of
the
CEN
workshop
on
Business
Interoperability
Interfaces
for
Public
Procurement
in
Europe
(CEN
WS
BII).
Through
PEPPOL
and
implementations
in
several
Member
States
and
Associated
Countries,
results
from
CEN
WS
BII
have
already
been
thoroughly
tested
and
have
proved
their
usefulness
in
practice.
2‐ Considering
the
specific
scope
of
the
draft
Directive
which
focuses
only
on
electronic
invoices
in
public
procurement
and
in
the
light
of
the
Commission’s
objective
to
achieve
end‐to‐end
electronic
procurement
to
modernise
public
administrations4
,
it
is
important
to
note
that
the
CEN
WS
BII
is
the
only
relevant
standardisation
initiative
in
Europe
that
supports
not
only
e‐Invoicing
but
also
the
complete
end‐to‐end
procurement
cycle.
3‐ OpenPEPPOL
supports
the
development
and
mandatory
use
of
a
common
semantic
data
model
of
the
core
electronic
invoice
based
on
existing
specifications
and
methodology,
developed
by
the
European
standardisation
organisation
(CEN).
OpenPEPPOL
recommends
that
the
results
from
the
CEN
WS
BII,
and
in
particular
that
the
CEN
Workshop
Agreement
(CWA)
16562,
is
used
as
basis
for
the
establishment
of
the
European
standard
for
the
semantic
data
model.
1
European
Commission
Proposal
for
a
Directive
of
the
European
Parliament
and
of
the
Council
on
electronic
invoicing
in
public
procurement.
COM(2013)
449
final.
Brussels,
26.6.2013
2
The
PEPPOL
Transport
Infrastructure
(PEPPOL
network)
is
based
on
a
set
of
standardised
communication
protocols
that
ensures
the
secure
and
reliable
exchange
of
electronic
documents
between
public
sector
buyers
and
their
suppliers.
For
more
information:
www.peppol.eu/peppol_components/‐transport‐infrastructure
3
The
Governance
of
the
PEPPOL
network
is
regulated
by
the
PEPPOL
Transport
Infrastructure
Agreements.
4
European
Commission
Communication
on
End‐to‐end
e‐procurement
to
modernise
public
administration.
COM(2013)
453
final.
Brussels,
26.6.2013
3
4‐ OpenPEPPOL
recommends
limiting
the
number
of
syntaxes
that
contracting
authorities
in
Europe
must
be
able
to
receive
and
process
based
on
the
European
standard
for
the
semantic
data
model.
This
in
order
to
reduce
the
cost
and
complexity
of
conversion
from
one
syntax
to
another,
that
are
significant
even
if
the
syntaxes
are
based
on
a
common
semantic
data
model.
The
before
mentioned
CWA
16562
provides
an
approach
for
syntax
binding
that
could
be
used
in
this
context.
While
the
number
of
mandatory
syntax
mappings
should
be
very
limited,
contracting
authorities
could
on
a
voluntary
basis
accept
to
receive
electronic
invoices
based
on
other
syntaxes,
compliant
with
the
common
semantic
data
model.
5‐ OpenPEPPOL
recommends
that
the
Commission
shall
be
empowered
to
adopt
delegated
acts.5
As
within
the
proposed
public
procurement
directive6
the
possibility
to
adopt
delegated
acts
should
be
given
to
ensure
the
interoperability
of
technical
formats
as
well
as
of
process
and
messaging
standards,
especially
in
a
cross‐border
context
to
establish
the
mandatory
use
of
such
specific
technical
standards.
For
e‐invoicing
this
could
cover
syntax
mappings
and
use
of
transmission
protocols
and
should
apply
only
where
technical
standards
have
been
thoroughly
tested
and
have
proved
their
usefulness
in
practice.
6‐ Based
on
the
experience
gained
in
European
countries
with
a
high
level
of
e‐Invoicing
adoption,
it
is
not
sufficient
to
focus
on
the
Contracting
Authorities’
obligation
to
receive
and
process
e‐invoices.
This
is
a
good
starting
point,
but
there
must
also
be
an
obligation
for
Economic
Operators
to
send
invoices
electronically
to
their
public
sector
customers.
OpenPEPPOL
recommends
as
a
minimum
that
Contracting
Authorities
are
given
the
right
to
mandate
the
use
of
e‐Invoicing
from
their
suppliers.
Ideally,
it
should
be
mandatory
for
all
Economic
Operators
to
send
invoices
to
their
public
sector
customers
electronically
as
has
been
done
in
Denmark.
7‐ OpenPEPPOL
recognises
that
the
time
required
to
develop
and
transpose
the
common
semantic
data
model
into
a
European
standard
will
be
between
2
to
3
years.
For
this
reason,
the
European
Commission
should
publish
a
clear
and
concise
roadmap
by
the
end
of
2013,
providing
guidance
to
the
market
in
the
interim
period.
OpenPEPPOL
also
recommends
that
the
Commission
consider
reducing
the
transposition
period
from
48
to
a
maximum
of
24
months.
5
The Treaty of Lisbon creates a new category of legal act: delegated acts. These ‘delegated non-legislative acts’
(Article 290 TFEU) are acts of general application to supplement or amend certain non-essential elements of the
legislative act. Furthermore, the legislator sets the conditions under which this delegation may be implemented.
6
Directive replacing Directive 2004/18/EC of the European Parliament and of the Council of 31 March 2004 on the
4
General remarks
1 Development of a European semantic data model
A
key
element
of
the
proposal
is
that
a
‘European
standard’
will
be
developed
within
the
framework
of
CEN,
as
evidenced
in
Article
3.
This
standard
refers
to
a
semantic
reference
model
for
the
core
content
of
an
eInvoice.
The
purpose
of
this
‘standard’
is
to
create
a
unified
concept
and
a
semantic
reference
model
for
e‐invoices
which
should
be
to
bridge
different
e‐invoice
formats
(syntax).
OpenPEPPOL
supports
the
development
of
a
common
semantic
data
model
of
the
core
electronic
invoice
based
on
existing
specifications,
including
in
particular
those
developed
by
European
or
international
organisations
such
as
CEN
Business
Interoperability
Interfaces
for
Public
Procurement
in
Europe
(CEN
WS
BII),
which
resulted
in
the
CEN
Workshop
Agreement
(CWA)
16562;
CWA
16356;
ISO
(Financial
Invoice
based
on
the
ISO
20022
methodology),
and
UN/CEFACT
(CII
v.
2.0),
as
well
as
the
results
of
any
relevant
work
carried
out
within
the
framework
of
the
Commission’s
Large‐Scale
Pilot
Projects.
OpenPEPPOL
recognises
that
significant
efforts
have
been
made
in
this
field
and,
in
order
to
make
the
task
easier
for
CEN
and
thereby
accelerating
the
process,
proposes
to
mandate
CEN
to
develop
the
semantic
data
model
thus
leveraging
the
results
of
CEN
WS
BII,
as
the
starting
point.
This
data
model
has
already
proved
its
value
in
the
PEPPOL
project
and
the
data
model
already
includes
syntax
mappings
to
both
the
Cross
Industry
Invoice
(CII)
and
the
Universal
Business
Language
(UBL)7
.
Moreover,
the
use
of
structured
formats
for
e‐Invoices
as
proposed
in
the
Directive
is
imperative
for
the
implementation
of
cost‐effective
solutions
with
efficient
support
for
(semi‐)automated
processing.
It
should
be
noted
however,
that
all
current
successful
examples
of
public
procurement
solutions
are
based
on
XML
technologies.
This
should
at
least
be
recognized
and
preferred
in
favour
of
older
technology
formats
such
as
EDIFACT
that
are
mainly
deployed
in
industry‐specific
areas
with
high
specialization
of
supply
chains.
Examples
of
widespread
use
of
EDIFACT
also
in
public
procurement
exist
in
Sweden,
but
use
of
XML
is
dominant
among
new
implementers
also
there.
Imposing
a
requirement
to
support
formats
other
than
XML
will
involve
additional
technologies
required
and
subsequent
increased
costs
for
all
public
Contracting
Agencies.
In
order
to
ensure
compliance
with
the
objectives
of
Directive
2006/112/EC,
the
European
standard
should
not
contain
requirements
for
electronic
signatures,
while
defining
semantic
data
elements
referring
to
corresponding
seller
and
buyer
data,
process
identifiers,
invoice
attributes,
invoice
item
details,
delivery
information,
payment
details
and
terms.
2 Implications and cost of conversion between formats
According
to
Article
4,
contracting
authorities
are
required
to
receive
all
e‐invoices
compliant
with
the
Semantic
data
model
as
a
part
of
the
European
Standard.
In
practice
this
means
that
Contracting
authorities
are
bound
to
receive
a
currently
unknown
number
of
e‐invoice
formats
and
syntaxes.
According
to
a
recent
study8
carried
out
by
the
Swedish
Financial
Management.
Authority
(ESV)
on
the
impact
of
the
draft
Directive,
none
of
today's
IT
solutions
have
the
capability
to
accept
an
arbitrary
e‐
7
Universal
Business
Language
(UBL)
is
a
library
of
standard
electronic
XML
business
documents
such
as
purchase
orders
and
invoices.
UBL
was
developed
by
an
OASIS
Technical
Committee
with
participation
from
a
variety
of
industry
data
standards
organizations.
UBL
is
owned
by
OASIS
and
is
currently
available
to
all,
with
no
royalty
fees.
8
Summary
of
the
report
on
consequences
of
the
directive
proposal
on
e‐invoicing
in
public
procurement
(ESV
2013:50).
5
invoice
format
in
an
automated
manner.
This
is
also
expected
to
lead
to
quite
substantially
increased
costs
for
contracting
authorities.
In
particular,
ESV
estimates
that
the
average
cost
to
establish
format
conversion
for
the
540
contracting
authorities
–
subject
of
this
analysis
‐
would
be
over
10
ml
euro
(SEK
95
million).
Approximately
half
of
this
cost
would
be
incurred
for
public
authorities,
without
taking
into
account
ongoing
transaction
fees
and
other
costs.
A
conclusion
to
be
drawn
from
this
is
that
the
cost
of
handling
format
conversions
is
the
single
largest
cost
item
brought
on
by
this
proposal.
Conversions
could,
according
to
ESV’s
calculations,
cost
twice
as
much
as
the
change
management
and
the
investments
made
by
the
few
agencies
currently
not
accepting
e‐Invoices.
The
alternative
is
for
each
agency
to
use
an
e‐Business
service
provider
to
handle
the
format
conversion
process,
which
also
comes
at
a
significant
cost.
However,
service
providers
are
now
also
realising
the
real
cost
of
‘any
to
any’
format
translations,
because
it
is
not
only
a
case
of
spending
more
money
to
support
more
variations.
Other
significant
cost
drivers
include
the
time
spent
on
getting
trading
partners
up
and
running,
the
need
to
simplify
the
process,
and
make
it
a
repeatable
process
(as
part
of
the
operation’s
life
cycle
management).
There
is
no
doubt
that
limiting
the
number
of
standards
significantly
limits
the
number
of
variations
but
this
directive
could
actually
serve
to
‘increase’
the
number
of
standards
used
(providing
they
all
incorporate
the
same
semantic
data
model).
Finally,
the
concept
that
several
approved
syntaxes
might
exist,
will
also
further
prohibit
software
providers
and
particularly
ERP
vendors
from
investing
in
a
single
e‐invoicing
standard
and
making
their
ERP
or
Accounting
software
capable
of
producing
‘ready
to
send
or
receive’
e‐invoice
export/import
capability,
which
would
make
e‐Invoicing
much
easier
for
SMEs.
3 – Adoption of Delegated Acts
According
to
Article
290
TFEU,
the
European
Commission
is
granted
the
power
to
supplement
or
amend
the
non‐essential
elements
of
a
basic
act,
for
the
sake
of
speed
and
efficiency,
through
the
adoption
of
Delegated
Acts,
which
represent
a
simplified
legislative
procedure.
According
to
article
19
section
7
a,
3rd
paragraph
of
the
proposed
public
procurement
directive9
,
the
European
Commission,
in
order
to
ensure
interoperability
of
technical
formats,
as
well
as
of
process
and
messaging
standards,
especially
in
a
cross
border
context,
is
empowered
to
adopt
delegated
acts
where
technical
standards
have
been
thoroughly
tested
and
proved
their
usefulness
in
practice.
The
current
list
in
the
proposed
public
procurement
directive
includes
e‐submission,
e‐catalogues
and
the
means
for
electronic
authentication.
Considering
the
potential
negative
impact
of
Article
4,
as
currently
drafted
in
the
draft
Directive
on
e‐
Invoicing
in
public
procurement,
OpenPEPPOL
recommends
the
European
Commission
to
adopt
a
Delegated
Act
to
supplement
the
technical
aspects
related
to
the
development
of
a
European
standard
for
the
semantic
data
model.
The
Delegated
Act
could
also
include
the
guidelines
and
reference
implementations
for
mapping
the
main
e‐Invoicing
syntax(es)
to
the
European
standard
for
semantic
data
model,
in
order
to
avoid
a
multitude
of
variations
in
future
e‐Invoicing
implementations,
as
well
as
use
of
transmission
protocols.
9
Directive replacing Directive 2004/18/EC of the European Parliament and of the Council of 31 March 2004 on the
coordination of procedures for the award of public works contracts, public supply contracts and public service contracts.
6
4 Timeline and Roadmap
OpenPEPPOL
recommends
to
reduce
the
transposition
period
of
the
Directive
from
48
to
maximum
24
months,
based
on
the
CEN
timeframe
to
develop
a
European
Standard
(see
figure
below).
Considering
that
market
developments
and
adoption
will
continue
over
the
next
few
years,
it
is
important
to
provide
a
clear
Roadmap
which
will
indicate
exactly
the
steps,
the
timelines
and
the
expected
results
of
the
work
required
to
develop
the
European
Standard.
It
will
be
equally
important
also
to
communicate
regularly
the
progress
made
by
CEN,
so
that
the
market
can
start
planning
the
testing
and
implementation
process.
Moreover,
significant
work
already
carried
out
within
CEN
BII
could
represent
the
starting
point
for
the
further
development
of
the
European
standard.
Therefore
it
should
be
possible
to
accelerate
the
technical
work
required
in
this
context
significantly
if
CEN
Workshop
Agreement
(CWA)
16562
is
used
as
basis
for
the
European
Standard.
5 Mandatory eInvoicing for suppliers to the public sector
Based
on
the
experience
of
countries
like
Norway
and
Denmark
which
enjoy
a
very
high
e‐Invoicing
adoption
level
in
the
business‐to‐government
context,
an
important
lesson
learned
is
that
mandating
the
receiving
capabilities
among
public
sector
entities
to
process
electronic
invoices
is
not
sufficient
to
promote
its
adoption.
Indeed,
a
two‐step
approach
is
highly
recommended.
For
example,
the
Norwegian
government
mandated
that
all
central
government
entities
should
be
able
to
receive
invoices
in
a
standard
format
from
1st
of
July
2011.
12
months
later
only
a
small
number
of
invoices
had
been
received.
Then,
from
1st
of
July
2012
it
became
mandatory
for
all
central
government
entities
to
require
their
suppliers
to
invoice
them
electronically
under
all
new
contracts.
14
months
later,
more
than
1
million
invoices
had
been
received.
Currently,
the
number
of
invoices
received
increases
at
20‐30
%
per
month
as
more
contracting
authorities
mandate
e‐invoicing
from
their
suppliers
when
entering
into
new
contracts.
In
Denmark
it
became
mandatory
for
private
companies
to
invoice
their
public
sector
customers
electronically
in
2005,
with
an
option
for
SMEs
to
send
paper
invoices
that
were
then
scanned
and
sent
electronically
to
the
public
sector
recipient.
This
gave
a
rapid
growth
in
number
of
invoices
received
fully
electronically
from
270.000
the
first
month
to
880.000
per
month
one
year
later.
7
Interoperability for eInvoicing in public procurement in Europe
1 CEN BII for public procurement in Europe
Introduction
The
objective
of
the
CEN
Business
Interoperability
Interfaces
(BII)
for
public
procurement
in
Europe
initiative
is
to
provide
a
framework
for
interoperability
in
pan‐European
electronic
procurement
transactions,
expressed
as
a
set
of
requirements
and
technical
specifications,
referred
as
‘BII
profiles’.
In
line
with
its
approved
business
plan,
the
focus
of
BII
is
to
collect
European
requirements
and
to
provide
guidance
for
consistent
implementation
of
these
requirements
utilizing
existing
international
developments,
i.e.
from
UN/CEFACT
and
OASIS
UBL.
The
actual
implementation
is
carried
out
by
the
user
communities
and
initiatives
such
as
PEPPOL/OpenPEPPOL
at
a
European
level.
The
fundamental
assumption
in
this
approach
is
that
in
order
to
achieve
the
goal
of
interoperability,
several
organizations
and
initiatives
need
to
work
together
–
each
contributing
with
their
piece
of
the
puzzle.
The
illustration
depicted
here
shows
the
specification
–
standards
–
implementation
eco
system.
To
acknowledge
and
continuously
improve
on
how
the
entities
of
this
eco
system
are
brought
together
is
key
in
securing
the
continued
success
and
expansion
of
e‐Invoicing
in
Europe.
Core requirements
In
the
context
of
BII,
it
is
recognised
that
the
required
information
content
of
each
business
transaction
will
depend
on
the
business
scenario
in
which
it
is
applied.
For
instance,
in
an
advanced
warehousing
scenario
there
may
be
a
need
to
provide
very
specific
information
elements
related
to
the
handling
and
storage
of
goods
not
generally
required
by
all
businesses.
It
is
also
recognised
that
with
an
aim
to
facilitate
true
interoperability,
there
is
a
need
to
define
the
minimum
set
of
information
elements
for
each
business
transaction
that
is
useful
and
understandable
in
all
business
scenarios.
Based
on
this
need
the
Information
Requirement
Models
defined
by
BII
intend
to
define
a
core
information
set
applicable
at
European
level.
This
core
set
of
information
elements
will
typically
support
the
majority
of
user
requirements.
Not
all
requirements
pertinent
to
industry
specific
needs
will
be
covered
by
the
core
information
elements.
However,
the
core
information
set
allows
for
industry
specific
adoption
using
the
combination
of
mandatory
/optional
elements
and
restrictions
/
extensions.
Although
the
deliverables
provided
by
BII
are
expected
to
be
ready
for
implementation
as
they
are,
the
focus
on
defining
the
core
information
set
also
implies
a
recognition
that
further
customization
may/will
be
required
by
user
groups
or
even
individual
users.
8
CEN BII profiles developed for eInvoicing in public procurement
The
CEN
BII
workshop
has
a
number
of
deliverables
that
are
relevant
for
e‐invoicing
in
public
procurement
and
the
proposed
initiative
to
develop
a
European
Standard
(EN)
for
a
Semantic
Data
Model
for
a
European
Core
eInvoice.
These
deliverables
are
relevant
not
only
for
the
Semantic
data
Model
itself,
but
also
for
the
methodology
relevant
for
its
development
and
adoption.
BII
deliverable
Comment
CWA16558
Annex
B
BII
Guideline;
Capturing
Of
Business
Requirements
Describes
a
methodology
for
how
to
identify
and
describe
business
requirements.
This
deliverable
is
currently
under
review
and
revision
in
CEN
WS/BII3.
CWA16558
Annex
C
BII
Guideline;
Conformance
And
Customizations
Describes
a
methodology
for
how
to
adopt
and
make
use
of
the
BII
Profiles
in
a
specific
business
context,
while
ensuring
continued
interoperability.
This
deliverable
is
scheduled
for
review
and
revision
in
CEN
WS/BII3.
CWA16562
Annex
B
BII
Profile
04;
Invoice
Only
This
profile
describes
a
process
comprising
only
a
supplier
initiated
electronic
Invoice.
It
is
intended
to
support
use
cases
where
the
invoicing
is
conveyed
in
an
electronic
format,
but
where
automation
of
matching
it
to
other
documents
is
not
required.
The
Invoice
is
a
self‐contained
document
that
adheres
to
commercial
and
fiscal
requirements.
It
is
not
a
primary
objective
of
this
profile
to
facilitate
automatic
order
matching
and/or
cost
allocation;
the
profile
assumes
limited
or
no
procurement
data
content
and
limited
or
no
aligned
and
synchronized
identifiers
in
the
system
to
match
the
transaction.
This
profile
may
cover
Invoice
factoring
arrangements
but
is
not
designed
for
self‐billing.
The
profile
includes
a
semantic
information
requirement
model
for
the
invoice
transaction.
CWA
16562
–
Annex
C
BII
Profile
05;
Billing
This
profile
describes
the
process
that
provides
support
for
the
processing
of
an
electronic
Invoice
and,
potentially,
an
electronic
Credit
Note,
or
just
an
electronic
Credit
Note.
It
is
intended
for
situations
where
invoicing
is
electronic
but
where
matching
of
the
Invoice
to
other
electronic
documents
may
not
be
practical.
The
Invoice
and
Credit
Note
are
self‐
contained
documents
with
that
adhere
to
commercial
and
fiscal
requirements.
Billing
inconsistencies
/
errors
are
notified
to
the
receiver
of
the
Invoice
and
then
resolved
by
the
issuing
of
a
Credit
Note
and/or
a
Corrective
Invoice.
This
profile
is
also
used
when
a
Credit
Note
needs
to
be
exchanged
for
other
reasons
than
for
correcting
an
Invoice.
It
is
not
a
primary
objective
of
this
profile
to
facilitate
9
automatic
Order‐Invoice
matching
and/or
cost
allocation;
the
profile
assumes
limited
or
no
procurement
data
content
and
limited
or
no
aligned
or
synchronized
identifiers
in
the
system
to
match
the
transaction.
The
Invoice
allows
for
the
use
of
text
as
well
as
identifiers
and
codes.
For
example,
the
Invoice
may
contain
items
(goods
or
services)
with
item
identifiers
as
well
as
items
that
are
referenced
using
free
text
descriptions.
This
profile
may
cover
Invoice
factoring
arrangements.
This
profile
can
be
used
with
little
or
no
integration
to
ERP
systems.
The
profile
includes
semantic
information
requirement
models
for
the
invoice
and
credit
note
transactions.
2 The PEPPOL project and OpenPEPPOL
Introduction
In
2008,
the
PEPPOL
(Pan‐European
Public
Procurement
Online)
project
was
launched
with
the
purpose
to
align
business
processes
using
common
standards,
address
common
legal
issues,
to
develop
technologies
available
as
open
source
and
to
create
an
open
and
accessible
network
that
would
cater
for
a
reliable
and
secure
exchange
of
information.
The
project
was
co‐funded
by
the
European
Commission
and
a
consortium
of
18
government
agencies
from
11
Member
States
and
Associated
Countries:
Austria,
Denmark,
Finland,
France,
Germany,
Greece,
Italy,
Norway,
Portugal,
Sweden
and
the
United
Kingdom.
PEPPOL
developed
the
Business
Interoperability
Specifications
(BIS)
for
common
e‐procurement
processes
such
as
e‐catalogue,
e‐orders,
and
e‐invoices
to
standardize
electronic
documents
exchanged
and
validated
through
an
open
and
secure
network,
between
sending
and
receiving
Access
Points
for
public
sector
buyers
and
their
suppliers
across
Europe.
A
Virtual
Company
Dossier
was
developed
for
suppliers
to
submit
company
information
in
a
standardized
‘re‐usable’
format,
an
e‐catalogue
for
use
in
the
tendering
process,
and
a
pan‐European
e‐signature
validation
service.
In
September
2012,
the
OpenPEPPOL
Association
was
set
up
in
order
to
assume
the
responsibility
for
the
maintenance
of
the
PEPPOL
specifications
and
to
promote
implementation
across
Europe.
Members
have
the
unique
opportunity
to
drive
standardisation,
process
automation
and
connectivity
across
Europe.
In
its
first
year
of
operation,
over
75
members
have
joined
from
both
the
public
and
private
sectors
in
18
countries,
with
over
60
PEPPOL
Access
Points
established.
Link between CEN BII profiles and PEPPOL BIS
Since
the
very
beginning
of
the
PEPPOL
endeavour,
the
BII
and
PEPPOL
initiatives
where
designed
to
constitute
complementary
entities.
•
CEN
BII
is
a
standardization
initiative
focusing
on
developing
standards,
in
the
form
of
CEN
workshop
agreements.
Its
deliverables
are
specifically
targeted
at
facilitating
electronic
procurement
and
invoicing
in
the
public
sector
in
Europe,
although
they
have
proven
to
be
useful
also
in
a
number
of
applications
in
the
private
sector.
•
PEPPOL,
and
now
its
successor,
OpenPEPPOL,
focus
on
implementation
and
practical
use
of
the
BII
deliverables
in
cross‐border
public
procurement
in
Europe.
10
Over
the
years,
CEN
BII
and
PEPPOL
have
developed
a
good
working
relationship,
and
also
share
many
of
the
same
stakeholders
and
participants.
PEPPOL BIS: a common denominator for crossborder eInvoicing
In
essence
the
PEPPOL
BIS
provide
the
stakeholders
–
service
providers,
systems
vendors
and
individual
organizations
who
implement
and
provide
PEPPOL
services
–
with
a
set
of
elements
that
leverage
the
CEN
BII
profiles.
These
additional
elements
will
guide
implementers
in
their
efforts.
Examples
of
PEPPOL
BIS
elements
that
complement
the
BII
profiles
are:
‐ Style
sheets
‐ Test
files
‐ Context
descriptions
(process,
use
cases
and
examples)
‐ Business
rules
‐ Message
structure
and
information
content
The
PEPPOL
BIS
for
a
specific
specification
is
also
accompanied
by
an
additional
document
–
the
conformance
statement.
This
document
describes
the
level
of
conformance
with
the
underlying
BII
specification,
clearly
stating
the
deviations
from
the
profile
specifications
(in
case
any
exist).
The
deviations
might
be
manifested
as
“restrictions”
or
“extensions”.
The
conformance
statement
constitutes
an
import
element
in
the
feed‐back
loop
mechanism
–
OpenPEPPOL
–
CEN,
as
it
provides
input
to
the
current
(or
upcoming)
workshop
in
terms
of
requirements
to
consider
for
future
versions
of
the
BII
specifications.
The
PEPPOL
BIS
form
the
basis
for
cross
border
exchange
of
the
information
covered
by
the
PEPPOL
BIS
set
of
elements
–
catalogue,
ordering,
invoice,
despatch
advice
and,
later
the
autumn
of
2013,
also
billing
(Invoice
and
credit
note)
and
message
level
response.
Using
common
specifications
to
exchange
e‐
Procurement
information
across
borders
offers
great
benefits
to
suppliers,
buyers
and
services/systems
alike.
The
PEPPOL
BIS
also
forms
the
basis
for
national
level
adoptions
of
the
CEN
BII
profiles.
The
Norwegian
EHF
specifications
constitute
an
example
of
this,
where
minor
adoptions
of
PEPPOL
BIS
are
done
to
cater
for
national
level
legislation
and
specific
considerations.
In
Sweden,
future
national
level
specifications
of
the
“SWE”‐family
of
specifications
(Swe‐Invoice/Svefaktura,
Swe‐Order/Sveorder
etc.)
are
expected
to
be
based
on
the
PEPPOL
BIS.
PEPPOL adoption for eInvoicing in public procurement in Europe
1. Austria:
From
2014,
eInvoicing
to
the
Federal
government
will
be
mandatory.
Use
of
PEPPOL
specifications
and
network
is
one
of
the
two
options
allowed.
2. Denmark:
National
eInvoicing
platform
‐
NemHandel
‐
(mandatory
since
2005)
is
PEPPOL
enabled.
3. France:
French
State
connected
to
a
PEPPOL
Access
Point;
UGAP
(Central
Governmental
Procurement
Agency)
planning
deployment
of
PEPPOL
e‐Invoicing
with
local
authorities.
4. Ireland:
Government
plans
national
roll
out
of
PEPPOL
with
7
active
Access
Points
already
in
place.
First
tender
requiring
use
of
PEPPOL
infrastructure
for
eInvoicing
published
in
August
2013.
5. Italy:
Intercent‐ER
(Emilia
Romagna)
with
many
Healthcare
authorities
and
ENI
implementing
eOrdering
&
eInvoicing;
Telecom
Italia
implementing
eInvoicing.
Region
of
Lombardia
to
implement
e‐Orders
with
PEPPOL
for
all
CAs
in
the
region
by
end
2013
‐
PEPPOL
Authority
to
be
set
up
by
2013.
Health
care
private
industry
already
collaborating
with
the
Regions
to
be
connected
to
PEPPOL
by
end
of
2013.
11
6. Netherlands:
National
eInvoicing
initiative
‘SimplerInvoicing’
piloted
the
PEPPOL
specifications
for
eInvoicing
in
the
B2B
and
B2G,
during
summer
2013,
with
successful
results.
Soft
national
roll‐out
to
be
announced
by
end
of
2013.
7. Norway:
From
July
2012
eInvoicing
to
the
government
is
mandatory,
based
on
PEPPOL
specifications
and
PEPPOL
network
use
was
recommended.
Vast
majority
of
central
government
organisations
can
receive
PEPPOL‐based
eInvoices.
8. Poland:
PEPPOL
to
be
part
of
the
national
e‐Invoicing
strategy.
Polish
Ministry
of
Economy
in
charge
of
implementing
the
eInvoicing
Directive
in
public
procurement
is
the
candidate
PEPPOL
authority.
9. Sweden:
Public
sector
eInvoicing
and
eOrdering
mandated.
PEPPOL
specifications
and
network
recommended
for
cross
border
use.
The
PEPPOL
BIS
increasingly
form
the
basis
for
the
national
level
e‐
Procurement
specifications.
As
an
example
of
this,
it
should
be
noted
that
the
new
national
level
Despatch
Advice
specification
is
based
on
PEPPOL
BIS
Despatch
Advice
in
its
entirety.
It
is
noteworthy
to
mention
that
OpenPEPPOL
AISBL,
in
its
first
year
of
operations,
has
recruited
over
75
active
member
organisations
across
18
countries.
While
initially
a
public
sector
focused
initiative,
OpenPEPPOL
members
include
large
global
multinationals
and
a
significant
number
of
SMEs
from
a
wide
range
of
industries
and
sectors.
3 Other initiatives: ZUGFeRD vs. BII/PEPPOL BIS
Introduction
ZUGFeRD
is
an
initiative
within
the
German
market
developed
as
a
result
of
cooperation
amongst
"members
from
the
public
administration,
three
German
federal
ministries,
industry
associations
in
the
financial,
tax
and
software
sectors,
and
other
organizations.
"
Currently
the
specifications
of
ZUGFeRD
are
available
in
German
language
only,
thus
a
detailed
analysis
of
all
aspects
of
this
initiative
has
not
been
possible.
We
have
been
informed
that
the
English
version
of
the
specification
will
be
made
available
during
November
2013.
Based
on
the
available
material
it
is
clear
that
ZUGFeRD
is
comprised
of
two
main
components:
1) a
semantic
data
model,
and
2) a
technical
implementation
(syntax
solution)
based
on
structured
XML
embedded
in
PDF
The ZUGFeRD semantic data model
The
ZUGFeRD
data
model
is
stated
to
be
based
in
the
Cross
Industry
Invoice
(CII)
from
UN/CEFACT.
However
an
analysis
of
the
material
available
(http://www.slideshare.net/oriolbausa/comparing‐zugferd‐
syntax‐with‐cross‐industry‐invoice‐v2)
suggests
that
there
are
significant
differences
between
ZUGFeRD
and
any
of
the
publicly
available
specifications
of
CII
from
UN/CEFACT.
The ZUGFeRD technical implementation
The
ZUGFeRD
technical
implementation
is
based
on
ISO
19005‐3
(PDF/A)
where
the
XML
invoice
data
is
embedded
in
the
PDF
document
as
an
attachment.
Although
this
may
look
like
an
attractive
solution
(combining
the
best
of
electronic
paper
and
structured
data)
similar
functionality
may
be
achieved
by
other
techniques,
such
as
XML
style
sheets.
The
use
of
XML
data
and
style
sheet
approach
is
significantly
more
widespread
than
use
of
PDF/A
for
handling
of
business
documents.
When
using
the
PDF/A
standard
there
is
also
a
risk
for
inconsistency
between
what
is
presented
in
the
PDF‐document
and
the
underlying
structured
data.
This
represents
a
potential
legal
uncertainty
within
a
PDF/A
approach
that
does
not
exist
in
an
XML
data
and
style
sheet
approach.
12
4 Conclusions
In
the
coming
months
it
will
be
critical
for
the
Commission
to
provide
a
clear
and
concise
Roadmap
of
the
coming
legislative
changes
and
recommendations,
particularly
during
this
period
where
both
the
private
and
public
sectors
are
investing
in
and
implementing
eInvoicing
solutions.
The
market
should
not
need
to
wait
until
the
legislative
and
standardisation
processes
will
be
completed.
The
Road
map
should
clearly
state
that
the
results
of
the
CEN
workshop
on
Business
Interoperability
Interfaces
for
public
procurement
in
Europe
will
be
used
as
the
basis
for
the
development
of
the
European
standard
for
the
semantic
data
model.
This
is
necessary
in
order
to
avoid
that
uncertainty
could
hinder
any
development
leading
to
a
situation
where
Member
States
and
contracting
authorities
will
not
be
able
to
make
decisions
on
any
e‐Invoicing
implementations
for
the
next
2‐3
years.
It
is
equally
necessary
that
Member
States
ask
their
contracting
authorities
to
implement
receiving
capability
for
e‐Invoices
within
1
year
following
the
publication
of
the
European
standard.
However,
MS
should
be
free
to
choose
the
preferred
syntax
for
cross‐border
and
domestic
e‐Invoicing
transactions
(or
more
than
one
syntax
if
they
so
desire),
as
long
as
it
is
compliant
with
the
European
standard
for
the
semantic
data
model.
It
is
important
to
clarify
that
PEPPOL
has
implemented
the
results
of
the
CEN
BII
workshop
(CEN
BII
profiles)
through
the
PEPPOL
specifications
(PEPPOL
BIS),
which
are
implemented
in
several
public
e‐Procurement
systems
and
currently
used
for
cross‐border,
national
and
regional
e‐Invoice
exchanges,
using
the
PEPPOL
network
as
the
transmission
channel.
Moreover,
experience
in
some
member
States
has
proven
that
mandating
e‐Invoice
receiving
capabilities
for
contracting
authorities
can
be
ineffective
unless
economic
operators
are
also
required
to
send
electronic
invoices
to
their
public
sector
clients.
The
deadline
for
public
sector
suppliers
to
send
invoices
electronically
to
the
public
sector
should
be
set
within
1
year
following
the
mandatory
deadline
for
contracting
authorities
to
have
their
receiving
capabilities
in
place.
About
OpenPEPPOL
As
the
Pan‐European
Public
Procurement
Online
(PEPPOL)
project
reached
a
successful
completion
at
the
end
of
August
2012,
with
the
PEPPOL
specifications
being
implemented
across
Europe,
the
OpenPEPPOL
Association,
comprised
of
public
and
private
members
of
the
PEPPOL
community,
has
taken
responsibility
for
all
activities
previously
carried
out
in
the
PEPPOL
project,
promoting
implementation
across
Europe.
For
more
information:
www.peppol.eu
