The other week I talked about using eBIS-XML as as way for SaaS/on-demand applications to exchange data between them. The idea is that an invoice raised by (say) Kashflow could be consumed by (say) Xero without the user having to worry about file conversions.
Ed Molyneux, CEO FreeAgent got in touch and suggested I had: ‘Not got the Simple UBL memo.’ Duh? Simple UBL offers an alternative way of data exchange that can be layered to a SaaS solution and achieve much the same effect. This is a new one on me so yesterday I took the opportunity of getting Ed to explain to me what this is about and what it means.
The atached video provides an outline. In speaking with Ed, it seems Xero quietly kicked off this idea, roping in FreeAgent and KashFlow as ‘founding members’ of this initiative. The thinking is that if a handful of well known SaaS providers declare and provide SUBL support then the remainder of the industry might be tempted to follow.
I’m not convinced. The way Ed explains it, SUBL will be used to support the email transport. In other words, invoices generated will be sent via email with the SUBL code attached along with standard PDF files. The user then gets the option to import to their chosen system or enter manually from the PDF. When I pulled a face at the idea, Ed countered by (correctly) pointing out that email is still and is likely to remain one of the principle business to business methods of communication. Looking out 5 years I am not so sure.
Implementing SUBL is not as clunky as it sounds but it still requires manual steps. I argued that eBIS-XML supported direct machine to machine import and is therefore far more reliable. Ed didn’t have a good answer but it seems that at least three players are having a go at SUBL integration.
Let’s be generous and assume they can 1. agree, 2 carry enough market mindshare to make it stick and 3. make it work. None or any of those issues are assured but even so…They are still inventing a new wheel where one already exists and which is superior albeit more irksome for the vendors to implement. But then that’s what they’re paid for – solving tricky problems the easy way.
While I welcome the idea, I think they’re low balling where in other areas the SaaS players are aiming much higher. Does it make sense to you? Will it stick?
Comments on this entry are closed.
Get into the conversation
Dennis,
It’s late, you’re tired, your annoyed with British transport – but the URL is wrong – should be http://www.simpleubl.org not .com
Yes, yes, I know it’s ironic.
Sorry Gary – I should have known – I saw the.org URL on Ed’s iPad and when I saw the .com stuff I thought: ‘That’s odd, doesn’t quite look the same’ but brushed it aside (as you do when it’s late and yer tired.) Anyhoo, fixed. Thanks
Any XML standard will ge transport independent. In New Zealand we’re working more broadly on a vendor neutral Virtual Mailbox concept that understands structured documents. Hopefully we can get this working in our small yet perfectly formed country and roll out in other jurisdictions.
@Rod: sure – I get that. It strikes me email is a half way house method and while I won’t claim enough geek cred to fully understand the issues, if you’re going to do this then why not just go the whole hog and aim for ‘machine to machine’ implementation? In similar vein, I really don’t get why eBIS-XML is being avoided. I hear something about paying for the documentation (is that right?) but given the relative size of the market and numbers of customer, is that such a big deal? Alternatively, it cant take that much pressure to get BASDA (or whomever is the copyright owner) to release eBIS-XML as a freely available standard.
Bottom line – I don’t really get why you all are re-inventing the wheel?
I certainly didn’t not have to pay for my copy of the basda ebis-xml specs. I am a basda member – but I am not even sure that is a requirement.
Dennis,
It's late, you're tired, your annoyed with British transport – but the URL is wrong – should be http://www.simpleubl.org not .com
Yes, yes, I know it's ironic.
Sorry Gary – I should have known – I saw the.org URL on Ed's iPad and when I saw the .com stuff I thought: 'That's odd, doesn't quite look the same' but brushed it aside (as you do when it's late and yer tired.) Anyhoo, fixed. Thanks
Any XML standard will ge transport independent. In New Zealand we're working more broadly on a vendor neutral Virtual Mailbox concept that understands structured documents. Hopefully we can get this working in our small yet perfectly formed country and roll out in other jurisdictions.
@Rod: sure – I get that. It strikes me email is a half way house method and while I won't claim enough geek cred to fully understand the issues, if you're going to do this then why not just go the whole hog and aim for 'machine to machine' implementation? In similar vein, I really don't get why eBIS-XML is being avoided. I hear something about paying for the documentation (is that right?) but given the relative size of the market and numbers of customer, is that such a big deal? Alternatively, it cant take that much pressure to get BASDA (or whomever is the copyright owner) to release eBIS-XML as a freely available standard.
Bottom line – I don't really get why you all are re-inventing the wheel?
I certainly didn't not have to pay for my copy of the basda ebis-xml specs. I am a basda member – but I am not even sure that is a requirement.
I can’t help but feel this is reinventing something that has already been invented.
The eBIZ-XML schema http://www.basda.org/ebis-xml-35485.htm was created by BASDA members who cover the spectrum of large and small vendors, so it works for large systems as well as small ones, it can be very easily applied, and it is already being used by thousands of businesses across the UK to my knowledge.
BASDA provide a toolkit to aid vendors in development and it has additional validation built in to check the message hasn’t been tampered with during transport.
There are also standards that need to be met to adhere to HMRC rules on electronic invoicing http://www.hmrc.gov.uk/vat/managing/charging/e-invoices.htm which arent mentioned here, i.e. you can’t just send XML from one app to another and that’s it… the process needs to comform with audit standards just as a paper invoice does today.
Most people use email, but we need to remember its not guaranteed delivery, or reciept, and can be inadvertantly deleted.
So, tell me why do we need another schema and what’s wrong with the BASDA one?
I can’t help but feel this is reinventing something that has already been invented.
The eBIZ-XML schema http://www.basda.org/ebis-xml-35485.htm was created by BASDA members who cover the spectrum of large and small vendors, so it works for large systems as well as small ones, it can be very easily applied, and it is already being used by thousands of businesses across the UK to my knowledge.
BASDA provide a toolkit to aid vendors in development and it has additional validation built in to check the message hasn’t been tampered with during transport.
There are also standards that need to be met to adhere to HMRC rules on electronic invoicing http://www.hmrc.gov.uk/vat/managing/charging/e-invoices.htm which arent mentioned here, i.e. you can’t just send XML from one app to another and that’s it… the process needs to comform with audit standards just as a paper invoice does today.
Most people use email, but we need to remember its not guaranteed delivery, or reciept, and can be inadvertantly deleted.
So, tell me why do we need another schema and what’s wrong with the BASDA one?
Is it not the case that eBIS-XML may well be the de jure standard, but its not the de facto standard?Which Sage products have standardised on eBIS-XML? I thought it was only Line 50, which admittedly is 150k+ UK customers (but I’d bet only a tiny subset of them use it), but also I understood the main rationale of Sage’s adoption of eBIS-XML was for it to be primarily used as the basis for Sage to Sage invoicing. It may be that other Sage products (UK and beyond) adopted it too, I don’t know.Beyond that and its adoption by larger ERP and procurement systems for supply into central government, it’s not attained the breadth of adoption it would have needed to provide the basis for the utopian network effect required for it to become the de facto electronic standard. In fact, I’d estimate that most electronic invoicing today is just conducted on PDF.If eBIS-XML had obtained de facto status, I’d get the wheel reinvention point. But has it?
I can't help but feel this is reinventing something that has already been invented.
The eBIZ-XML schema http://www.basda.org/ebis-xml-35485.htm was created by BASDA members who cover the spectrum of large and small vendors, so it works for large systems as well as small ones, it can be very easily applied, and it is already being used by thousands of businesses across the UK to my knowledge.
BASDA provide a toolkit to aid vendors in development and it has additional validation built in to check the message hasn't been tampered with during transport.
There are also standards that need to be met to adhere to HMRC rules on electronic invoicing http://www.hmrc.gov.uk/vat/managing/charging/e-invoices.htm which arent mentioned here, i.e. you can't just send XML from one app to another and that's it… the process needs to comform with audit standards just as a paper invoice does today.
Most people use email, but we need to remember its not guaranteed delivery, or reciept, and can be inadvertantly deleted.
So, tell me why do we need another schema and what's wrong with the BASDA one?
Is it not the case that eBIS-XML may well be the de jure standard, not its not the de facto standard?
Which Sage products have standardised on eBIS-XML?
I thought it was only Line 50, which admittedly is 150k+ UK customers (but I'd bet only a tiny subset of them use it), but also I understood the main rationale of Sage's adoption of eBIS-XML was for it to be primarily used as the basis for Sage to Sage invoicing. It may be that other Sage products (UK and beyond) adopted it too, I don't know.
Beyond that and its adoption by larger ERP and procurement systems for supply into central government, it's not attained the breadth of adoption it would have needed to provide the basis for the utopian network effect required for it to become the de facto electronic standard. In fact, I'd estimate that most electronic invoicing today is just conducted on PDF.
If eBIS-XML had obtained de facto status, I'd get the wheel reinvention point. But has it?
Hi Gary, I think you may be missing my point here.
This isn’t about Sage (other than to say you’re way off the mark, I’m not prepared to talk detailed customer numbers.)
This is about a recognised industry body BASDA having developed a similar, if not more refined, schema in collaboration with their members, who comprise most of the major business software vendors in the UK.
Why do the aforementioned vendors feel it is necessary to start from scratch… which is the point of my reinventing the wheel comment… would it not be better to join with the other BASDA members and build on what they have already produced… that way we all have a better chance of delivering a defacto standard for our mutual customers?
Hi Gary, I think you may be missing my point here.
This isn't about Sage (other than to say you're way off the mark, I'm not prepared to talk detailed customer numbers.)
This is about a recognised industry body BASDA having developed a similar, if not more refined, schema in collaboration with their members, who comprise most of the major business software vendors in the UK.
Why do the aforementioned vendors feel it is necessary to start from scratch… which is the point of my reinventing the wheel comment… would it not be better to join with the other BASDA members and build on what they have already produced… that way we all have a better chance of delivering a defacto standard for our mutual customers?
Any news on Simple UBL? Nothing seems to have changed much on their website. Is it yet possible to email an XML invoice between different web-based accounts packages? (I use Xero, and I don’t think I have this option)
Get into the conversation