Electronic Invoices as PDF/A, According to Italian Law

Which role does PDF/A play for electronic invoices in Italy?

Italian Legal Requirements

Italian laws prescribe requirements for electronic documents, their reproduction and storage. Let’s take a rapid look, focusing only on some specific regulations that a service creating electronic invoices needs to conform to:

  • A bill dated January 23rd, 2004 from the Ministry of the Economy and Finance contains the fundamental definition of an electronic document: static and non-modifiable documents are drawn up in such a way that the content cannot be modified during access and storage, and the document remains unchanged over time.
  • Article 3 of this regulation defines the requirements for electronic documents relevant for tax purposes: they need to be electronic documents issued by affixing a time reference and a qualified electronic signature, in order to ensure certification of date and their authenticity and integrity.
  • Article 6 specifies that electronic documents must be made legible and, on request, available on hardcopy or electronic medium at the place of storage, in case of verifications, audits or inspections.

This law is an update of many older ones and was passed to guarantee that electronic documents will have the same value as paper document, especially for tax purposes and in case of verifications and audits. Electronic documents can be created in many ways, but only the ones that are completely comparable to paper documents conform to the law.

The main purpose of the law was to integrate electronic invoices (that only make up a small portion of all documents received by companies) into the inspection system: making a hardcopy of them would leave the method of inspection as before. The electronic invoices should replace the paper pages. Since the inspection results could have an important influence on our customer’s business, these legal requirements also have some implications on the datastream format of electronic documents.

The electronic processes used for representing electronic documents will be compared in the following section.

XML vs. PDF

In the past, TIFF files were used for generating, reproducing and storing documents. But we had to improve services to give our customer more flexibility, usability and other new special services. TIFF files were not viable for the radical upgrade we wanted to do, so we focused on XML and PDF. As opposed to TIFF, these file formats not only represent a document, but can in addition be a carrier of other information and used in different systems.

Therefore we examined XML flows and PDF files to understand which of them could be the right format to respect all legal requirements for electronic document representation, particularly for electronic invoices.

A digitally signed XML flow is always non-modifiable: it can’t contain anything that modifies its content, so its representation will never change without invalidating its digital signature.

A digitally signed PDF which includes JavaScript, or other advanced features that could be used to modify its content, could theoretically change its representation itself without invalidating the digital signature. However, a PDF can only be used for electronic invoices, according to Italian law, if it doesn’t have features that could modify its content. This is a disadvantage to using standard PDF files.

Both formats support time references as well as a qualified electronic signatures, and they are recognised world-wide.

Although PDF files are usually human readable (in the same way as paper documents, if they are correctly interpreted by a browser’s rendering engine), printable and can be sent by e-mail, an XML flow is not human readable without specific knowledge and its own XML schema. It can be printed and sent by e-mail, but its paper representation doesn’t look like the original document (the paper used before switching to electronic document). This is a disadvantage for XML, because human readability is absolutely necessary for verifications, audits or inspections.

For XML dataflows, Italian law restricts the addressees who may receive a document, and allows the use of an XML dataflow environment to only those customers with a signed agreement. This restriction could generate a complex management of contracts with customers which can be avoided with PDF, because PDF files can be used by everyone without any restrictions.

Electronic Invoice for E-Mission

Since we must guarantee that a document cannot be modified, the only way to create electronic invoices that conform to Italian law is to use PDF files. However, there aren’t any universally recognised methods for creating an unalterable PDF – or at least, there weren’t…

PDF/A

PDF/A-1 is an ISO standard for long-term archiving. It was published on October 1st, 2005 based on the PDF Reference Version 1.4 from Adobe Systems Inc. PDF/A files are viewable now and in the future on every system, independent of producer, operating system and viewer: it’s a “self referring” format with all resources embedded in the same file.

PDF/A stores objects, allowing for an efficient full-text search in an entire archive, and requires only a fraction of the memory space of original or TIFF files without loss of quality. A typical invoice, consisting of an image with one or two different standard fonts for text, saved as a TIFF file at 300 dpi requires 50 Kbytes. Saved as a PDF/A file it requires at most 35 Kbytes.
Metadata like title, author, creation date, modification date, subject, keywords, etc. can be stored in a PDF/A file. PDF/A files can be automatically classified based on the metadata, without requiring human intervention.

Electronic documents in PDF/A format can contain metadata for automatic archiving or for carrying data to receivers. Creating a proper XMP extension schema makes it theoretically possible to load all metadata that are contained in the files in another representation, or to load all the information that are necessary for receivers into a PDF/A file.

JavaScript and advanced feature that add interactivity or modify content are not allowed, so PDF/A could be the right file format for saving electronic invoices according to Italian laws. Digitally signing a PDF/A file of an invoice respects all the restrictions dictated by Italian law. PDF/A files could be checked by third party analysers and validators. Then the inspectors would have the instruments to check that the PDF file is really a PDF/A file and is conforming to legal restrictions.

Electronic Invoices as PDF/A for E-Mission

Respecting the PDF/A standard and using qualified electronic signatures can guarantee compliance with all Italian legal requirements – now and probably in the near future. Since PDF/A features may be the only ones that perfectly conform to Italian legal requirements, the electronic invoice for E-Mission is a PDF/A conforming file, with time reference and qualified electronic signature embedded and external UBL (Universal Business Language) data linked to the document.

UBL (Universal Business Language), a little widening

Since its approval, XML has been adopted in a number of industries as a framework for the definition of the messages exchanged in electronic commerce. The widespread use of XML has led to the development of multiple industry-specific XML versions of such basic documents as purchase orders, shipping notices, and invoices.

While industry-specific data formats have the advantage of maximal optimization for their business context, the existence of different formats to accomplish the same purpose in different business domains is marked by a number of significant disadvantages as well.

  • Developing and maintaining multiple versions of common business documents like purchase orders and invoices is a major duplication of effort.
  • Creating and maintaining multiple adapters to enable interfacing across domain boundaries is an even greater effort.
  • The existence of multiple XML formats makes it much harder to integrate XML business messages with back-office systems.
  • The need to support an arbitrary number of XML formats makes tools more expensive and trained workers harder to find.
  • The OASIS Universal Business Language (UBL) is intended to solve these problems by defining a generic XML interchange format for business documents that can be extended to meet the requirements of particular industries. Specifically, UBL provides the following:
  • A library of XML schemas for reusable data components such as “Address,” “Item,” and “Payment” — the common data elements of everyday business documents.
  • A set of XML schemas for common business documents such as “Order,” “Despatch Advice,” and “Invoice” that are constructed from the UBL library components and can be used in generic procurement and transportation contexts.

UBL is designed to provide a universally understood and recognised commercial syntax for legally binding business documents. It operates within a standard business framework such as ISO 15000 (ebXML) to provide a complete, standards-based infrastructure that can extend the benefits of existing EDI systems to businesses of all sizes. UBL is freely available to everyone without legal restrictions or licensing fees.

UBL schemas are modular, reusable, and extensible in XML-aware ways. As the first standard implementation of ebXML Core Components Technical Specification 2.01, the UBL Library is based on a conceptual model of information components known as Business Information Entities (BIEs). These components are assembled into specific document models such as “Order” and “Invoice”. These document assembly models are then transformed in accordance with UBL naming and design rules into W3C XSD schema syntax. This approach facilitates the creation of UBL-based document types beyond those specified in this release.

The decision to use UBL files to carry data to receivers as external XML simplifies the service:

  • when an XMP extension schema is created, all the PDFs that contain the metadata must load it (need to be self referring)
  • UBL is a standard; creating a new XMP extension schema could be a duplicate
  • not all customer’s users need to receive accounting data using the service

The link between PDF/A and UBL is made by filenames and standard metadata saved in the PDF/A.

E-Mission.Weaver

The purpose of E-Mission.Weaver is to automate the entire supply cycle and to carry electronic invoices from suppliers to customers. E-Mission.Weaver can be used from the order to the payment, and in each phase an electronic document can be generated as PDF/A for visualisation and storing in document management systems.

A common flow between a company and its suppliers and customers when using E-Mission.Weaver.

E-Mission is the link between parties: it receives data spools from the suppliers, generates electronic invoices and creates UBL containing accounting data (the Italian law allows for a service provider to emit invoices for another company). Then it sends all the electronic invoices and the accounting data to the service user (E-Mission customer).

The flow can also be directed to the end-customer. The invoice spools are received by E-Mission, which creates electronic invoices for the service user. The data extracted from the spools is saved in UBL, enabling the end-customer to automatically load it into his accounting system.

The cycle can be a closed-loop with the return of invoice recording data and payment data. All of the documents emitted are optically substituive stored according Italian law using Archiva services.

E-Mission S.r.l. started its business in October 2008 as a spin-off of Archiva S.r.l., which has been on the market since 1979 with substitutive optical document storage. All document distribution services were entrusted to E-Mission with the target of completely automating and improving them.

The main activities of E-mission are:

  • examination and updating of all national and international standards for document storage and transmission
  • development of new technologies that include data and document transmission and sharing between different and heterogeneous business partners
  • consultation to develop dedicated customer solutions that result from an analysis of their corporate requirements and processes
  • implementation with customers of the data transmission and sharing services, using the solutions that have been selected
  • in-house management of the processes that provide the services

Currently the company handles the transmission of documents of any type and nature (commercial, tax, administrative, technical, etc.) in hardcopy and through electronic mailing services. With Weaver it has completed its range of services being offered with the transmission of the data contained in these documents, creating a new transmission engine open to all new technologies and all present and future communications standards (XML, EDI, etc.).

Weaver – Basic Implementation Level

The first implementation phase is the generation of invoices for a supplier (E-Mission emits invoices in his name according to Italian laws). Electronic invoices in PDF/A (with time reference and qualified electronic signature embedded), and data contained in them saved as UBL files, are transmitted between the parties.

The supplier sends his invoice spools to E-Mission. The service creates PDF/A electronic invoices and UBL data for all customers of the supplier. When one of the customers logs into the service, E-Mission.Weaver sends him all electronic invoice addressed to him and all the data contained in the UBL, for direct loading into his account system.

invoice

All data exchanges are made by using a custom web service. UBL data is only used for storage information, but it is sent using the interface to avoid customers having to keep up to date with UBL upgrades.

The customer can put references to invoice records in the database to E-Mission.Weaver, delivering them to the supplier when he logs into the service. This helps control the cycle.

 

After payment, the customer gives the payment reference for downloaded invoices to E.Mission.Weaver. These are delivered to the supplier to close out the cycle (after bank account verification).

payment

This level of implementation can be adopted by all E-Mission customers, independent of whether they are suppliers or customers (or both).

Service structure

E-Mission.Weaver was created on a server structure that guarantees the best levels of security, redundancy, consistency and traceability. The web service is a WCF service (Windows Communication Foundation) based on SLL layer and accessible by all types of systems. The binding force to use a specific certificate for all request to the E-Mission.Weaver’s service is another level of security and it is also a way of having traceability for all transactions.

The use of distributed sessions increases consistency levels to the best available, avoiding differences between supplier and customer accounting systems.

All PDF/A files are generated using PDFlib libraries (PDFlib, PDFlib TET and PDFlib PLOP). We worked with the PDFlib development team to support the use of Italian smartcards during the electronic qualified signing of PDF/A.

Weaver – Extended Service Levels

In another implementation, E-Mission.Weaver integrates the management of delivery notes and invoices with the transfer of transaction data and PDF/A documents between suppliers and customers, for both types of documents.

In this instance, the process starts with the delivery of goods (or services). The supplier sends a delivery note spool to E-Mission, which in turn creates PDF/A electronic delivery notes and UBL data for all customers. When a customer logs into the service, E-Mission.Weaver transfers to him all of his electronic delivery notes and all the data contained in the UBL, for direct loading into his warehouse system.

Then the process continues with the management of the invoices linked to already processed delivery notes processed as described above.

In this phase, customers are able to load the transaction data into their warehouse system, even before the goods arrive!

In the next version that’s under development, E-Mission.Weaver will handle the complete supply chain with the integrated management of orders, delivery notes and invoices, including the data transfer and the exchange of the PDF/A documents, between suppliers and customers.

The process starts with the order being placed and entered by the customer and introduced into the E-Mission.Weaver service, sending an order spool to E-Mission. When the supplier logs into the service, E-Mission.Weaver sends him all the pending orders. After this step, the process will continue with the management of delivery notes and associated invoices.

The process finishes by releasing the process data into EDI workflows, enabling service users to fulfil all their customer requirements without any limitation.

Italian law and PDF/A

Finally, there is an important news about PDF/A and Italian law: for the first time, the Italian Government has written a law that refers to PDF/A instead of generic PDF. The Prime Minister’s decree dated December 10th, 2008 concerning “balance sheet presentation to registry office in XBRL” (eXtensible Business Reporting Language) contains the possibility of using PDF/A file format instead of XBRL files for the balance’s presentation, if the accounting system is not able to generate XBRL files.

It might seem like a small detail, but the decree is a part of the “eGov2012” plan and it could be the starting point for officially adopting PDF/A format as a standard in Italy.

That’s what we and the rest of the PDF/A Competence Center are hoping for…
—-

References

http://www.pdfa.org
http://ubl.xml.org
http://www.pdflib.com
http://www.funzionepubblica.gov.it/ministro/pdf/DPCM_10dicembre2008.pdf (only in Italian)
http://www.governo.it/governoinforma/dossier/piano_e_gov_2012/ (only in Italian)

http://Italian laws prescribe requirements for electronic documents, their reproduction and storage. The main purpose of the law is to integrate electronic invoices (that only make up a small portion of all documents received by companies) into the inspection system.

About Domenico Barile

Leave a Reply