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.