An e-commerce software specialist is advising that sending XML
(eXtensible Markup Language) invoices without approval of HM
Customs & Excise and other European agencies responsible for
collecting VAT can lay users open to severe penalties.
Perwill plc, based in Alton, Hampshire, this week warned that HM
Customs & Excise (HMC&E) and other European agencies
responsible for the collection of VAT need to be consulted before
paper copies of invoices, credit and debit notes that include
VAT-bearing transactions can be replaced electronically.
Perwill points out that strict rules and procedures already
exist for conducting such transactions using Electronic Data
Interchange (EDI), and that similar rules apply to XML
implementations. Perwill MD Bill Pugsley states that many
organisations do not realise they may be breaking the law and
potentially leaving themselves open to severe penalties, simply by
sending XML-based invoices.
XML is similar to Hypertext Markup Language (HTML). HTML,
however, describes the content of a web page (mainly text and
graphic images) only in terms of how it is to be displayed and
interacted with. XML describes the content in terms of what data is
being described. XML is used as a more flexible way to cerate
common information formats. It has become popular as a means of
exchanging business data.
Unlike traditional Electronic Data Interchange (EDI), a standard
format for exchanging business data, XML offers the dual benefits
of permitting data to be read by humans, while also having a
structure that lends itself to automatic ‘reading’ by receiving
systems. Much has been written about using XML to transact all
levels of business, from sending a request for quotation to
receiving an invoice. Many people are under the impression that
because electronic financial instruments (invoices, credit &
debit notes) containing VAT-able elements can be transacted using
EDI, they are also permitted using XML messaging. Perwill says that
this is not the case.
Any company or organisation that wishes to switch from paper
documents to rely solely on XML-based transactions, first needs to
secure the agreement of HMC & E. Perwill points out that,
“without such approval, an unpleasant surprise may be lying in wait
at the next HMC&E audit. The same condition applies to any
organisation wishing to receive XML instruments.”
Where HMC&E have been given due notice and a single XML
financial instrument is sent (typically over the internet),
provided both parties keep a copy for the statutory six years,
there is unlikely to be a problem. According to Bill Pugsley,
however, complications arise with multiple transactions. He
comments: “Where several transactions are being sent in the same
batch (as a single attachment to an e-mail for example), the sender
should also create a summary message that contains hash totals of
the value fields of “each type” of transaction. So if credit notes
are sent with invoices, there needs to be a summary XML set for
credit notes and a separate summary set for invoices.”
Pugsley continues: “The recipient of the XML message should then
recalculate (hash total) the received transactions and compare the
calculated results against the received summaries. If there is a
mismatch in calculations (which suggests data has been corrupted
en route), then either the data can be accepted (and the
recipient must tell the sender where the problem lies) or the
recipient can reject the batch of data that is in error. It’s a not
a straightforward process and there’s plenty of room for
error.”
Assuming that the sender has agreed (a mandatory 28 days notice
is required) with their local HMC&E office that they can send
XML financial instruments to specific customers, (and the customers
have also given 28 days notice to their own HMC&E offices),
then paper copies are unnecessary. Without the notice and the
summary reports, however, paper copies of transactions should still
be sent and all parties are expected to declare which is the
document for tax purposes (the XML or paper copy). Without such a
declaration, and a demonstration that a procedure is in place to
use only “one set of data” for the purposes of reconciling VAT (not
two sets of data leading to possible duplication of records), it is
unlikely that a company’s HMC&E inspector will accept the
delivery of data in duplicate.
Perwill recommends that the best solution is to generate the
necessary control records (in XML format) and, where such data is
received, to verify the control totals being delivered. Ideally a
control print should also be produced, stating what has been
received and what was calculated.
Bill Pugsley commented: “BASDA [Business Application Software
Developers Association] is actually working on a suggested template
for the XML messages needed to provide the ‘controlling data’. The
resulting template should be suitable for businesses wishing to
‘trade’ financial instruments using XML data structures.” He
concluded: “I’m happy to say that the Perwill eBiz Manager product
set already offers this capability, so no Perwill customer will be
caught in this VAT trap.”
Perwill can be found at www.perwill.com.
