Ask HN: Why aren't there HTTP style standards for invoicing things?
30 comments
EDI, it's old and crusty and expensive and annoying because all of the current software out there is crap but it solves this for companies as big as WalMart down to your local Mom and Pop corner store. I have a pretty good idea how to fix this but have other commitments at the moment. Too many ideas not enough time. A PO is the 850 document standard in EDI and the invoice is the 810 in EDI.
I'm getting the feeling this is the thread to figure out who the old folks are.
Yep, EDI is cranky and a pain, but there is a lot of expertise out there and some of the software is not totally heinous (unless we are talking health information via EDI, then it all sucks and you might have to learn MUMPS / M). There are standards.
Yep, EDI is cranky and a pain, but there is a lot of expertise out there and some of the software is not totally heinous (unless we are talking health information via EDI, then it all sucks and you might have to learn MUMPS / M). There are standards.
ANSWER TO YOUR GENERALISED QUESTION:
cXML http://cxml.org/ , OCI and EDI (mentioned above) are alive and well and commonly used for large corporates to deal with their suppliers without paper.
cXML (or even OCI) for the purchase order stage and EDI for the invoice stage is a typical setup.
ANSWER FOR YOUR SPECIFIC ISSUE:
The reason this doesn't and will never exist is that every business is different - you're essentially dealing with people like Joe Bloggs not standardised processes like HTTP. However, help is at hand:
https://www.receipt-bank.com/ - they take your email and paper invoices in any format, scan them, key in the data and inject it straight into your accounts system (or at least let you grab a spreadsheet).
cXML http://cxml.org/ , OCI and EDI (mentioned above) are alive and well and commonly used for large corporates to deal with their suppliers without paper.
cXML (or even OCI) for the purchase order stage and EDI for the invoice stage is a typical setup.
ANSWER FOR YOUR SPECIFIC ISSUE:
The reason this doesn't and will never exist is that every business is different - you're essentially dealing with people like Joe Bloggs not standardised processes like HTTP. However, help is at hand:
https://www.receipt-bank.com/ - they take your email and paper invoices in any format, scan them, key in the data and inject it straight into your accounts system (or at least let you grab a spreadsheet).
Short answer there are, look up EDI Electronic data interchange which has been going longer than some HN commentators have been alive
http://en.wikipedia.org/wiki/Electronic_data_interchange
EDI was live back in the early 80's in the UK
http://en.wikipedia.org/wiki/Electronic_data_interchange
EDI was live back in the early 80's in the UK
And it's still alive now and still a fucking arse pain. We have to import statements from various large financial companies and they still even after 20-odd years haven't worked out how to make parseable CSVs and don't even get me started on encoding which usually consists of concatenated bits of crap in multiple encodings. Oh and some of it even arrives via modem (at 9600bps no less!). If we're lucky we get SFTP and UTF8 XML without a broken schema. Some of the XML is actually just made by concatenating unescaped strings which explodes when someone puts a double quote in a text field.
Imagine debugging that heap of shite.
Resolving problems with it does pay very well though, which is what I'm doing now at 23:25 on a Sunday night :)
Imagine debugging that heap of shite.
Resolving problems with it does pay very well though, which is what I'm doing now at 23:25 on a Sunday night :)
Yet for some reason, paper invoices, carbon paper, still arrive at stores with the boxes of goods.
Well there is a bunch of standards aimed at this, already mentioned are EDI and cXML. But another very ambitious is Oasis' UBL. In Denmark and a few other european countries you basically have to support invoicing in UBL (Or more specifically the danish subset OIOUBL or scandinavian subset NESUBL) if you want to do business with government as it is a requirement.[1] In a transition-phase (which i don't know if still is ongoing) suppliers could send invoices to a "scanning agency" that would attempt to convert the invoice to OIOUBL and send on to the government institution.
This has pushed adoption of these things in Denmark quite a bit and we see a lot of big corporations demanding of their suppliers that they support these formats.
Edit: [1] Previous to OIOUBL danish government had its own format called OIOXML: http://en.wikipedia.org/wiki/OIOXML
This has pushed adoption of these things in Denmark quite a bit and we see a lot of big corporations demanding of their suppliers that they support these formats.
Edit: [1] Previous to OIOUBL danish government had its own format called OIOXML: http://en.wikipedia.org/wiki/OIOXML
There are to many conflicting standards for this. Most of them are calling themself some 'EDI', even those that are not based on X12. X12 itself is not human readable, and EDI based on X12 (Tradacom, US EDI, UN/EDIFACT) are complex beasts. To complex for average coders. So those coders invent new standards e.g. for SAP, or OASIS.
imho, the solution would be UN/EDIFACT. The United Nations version is flexible enough to cover 99% of the real life cases, and improves twice a year, to cover the remaining percent.
Take a look at my XML::Edifact CPAN Perl modules, if you want to start with free software EDI.
Now EDI is only half of the bill. EDI would be the HTML part of the Web of business documents. But you also need a transport part, and the EDI networks are not connected, as they speak different languages. And you need some open servers and browsers for your EDI.
imho, the solution would be UN/EDIFACT. The United Nations version is flexible enough to cover 99% of the real life cases, and improves twice a year, to cover the remaining percent.
Take a look at my XML::Edifact CPAN Perl modules, if you want to start with free software EDI.
Now EDI is only half of the bill. EDI would be the HTML part of the Web of business documents. But you also need a transport part, and the EDI networks are not connected, as they speak different languages. And you need some open servers and browsers for your EDI.
payswarm is building monetary & transactional schemas/data-models. they have json-ld underneath, and jsonld has some interop with RDFa if you want the other declarative content format (html). https://payswarm.com/specs/ http://digitalbazaar.com/payswarm/
i'm less familiar with the other ideas floating in the Web Payments working group, whose charter is to chart the standards serving what you describe. http://www.w3.org/community/webpayments/
i'm less familiar with the other ideas floating in the Web Payments working group, whose charter is to chart the standards serving what you describe. http://www.w3.org/community/webpayments/
"Adoption seems like the answer to my question."
Established legacy process that is working. Also as noted people spend money and give effort to make money I don't think this is a big enough pain point in terms of saving money.
In order to make this happen you would have to start by convincing (say) Walmart that it was good for them. Then they would force it down the throats of their vendors. Believe that happened with bar codes. I remember doing a job for a small business that was a Walmart vendor and needed bar codes (this was a long time ago the early 90's) in order to ship an order.
That said your writeup isn't that clear in stating the problem. I had to read it twice to understand what you were asking.
Established legacy process that is working. Also as noted people spend money and give effort to make money I don't think this is a big enough pain point in terms of saving money.
In order to make this happen you would have to start by convincing (say) Walmart that it was good for them. Then they would force it down the throats of their vendors. Believe that happened with bar codes. I remember doing a job for a small business that was a Walmart vendor and needed bar codes (this was a long time ago the early 90's) in order to ship an order.
That said your writeup isn't that clear in stating the problem. I had to read it twice to understand what you were asking.
Sorry about being unclear. It was more of a rant in the form of a question.
I don't think this would be a walmart down thing but instead a "the valley out" thing - kind of like REST and APIs are today.
I don't think this would be a walmart down thing but instead a "the valley out" thing - kind of like REST and APIs are today.
The people who built the Danish e-invoicing solution are called Tradeshift and have a solution which follows open standards.
They've also recently added cloud scanning. If you're a corporate you can buy access for your suppliers to email pdfs to Tradeshift - and the magic is the supplier gets an email back asking them to validate the data. And emails telling them how much easier it would be to submit electronically in the first place.
Much more elegant than the payment networks which charge the supplier a flat fee to submit an invoice.
Are you sure there are no such standards? I mean - in Czech Republic we have de facto standard called ISDOC XML(which should be based on other international standard UBL (universal bussines language, or smtg. like that)). All major accounting/finance software support it and yet, nobody uses it (at least those I have to deal with). I couldn't even convince my ISP to send me these files.
Maybe you should check current options and then require them from your vendors.
Part of the problem is that problem domain for small businesses doesn't look the domain for large businesses.
For one thing, large businesses often have to deal with multiple country rules.
All my invoices are issued to Australians, at the moment (though I'm open to invoicing others, hint hint). So it's fairly straightforward; my invoice template includes the legal requirements of an ABN, business number, the words "Tax Invoice", an identifying number and prices with and without tax.
If I bill in other countries, I might need another template.
If I bill in a pile of other countries, then any universal system has to account for per-country variations in an abstract, generalisable way.
But abstract, generalised ways of doing things obscure the concrete case. Instead of thinking in local terms, I have to learn the generic term and then understand how it will map to my particular problem.
For one thing, large businesses often have to deal with multiple country rules.
All my invoices are issued to Australians, at the moment (though I'm open to invoicing others, hint hint). So it's fairly straightforward; my invoice template includes the legal requirements of an ABN, business number, the words "Tax Invoice", an identifying number and prices with and without tax.
If I bill in other countries, I might need another template.
If I bill in a pile of other countries, then any universal system has to account for per-country variations in an abstract, generalisable way.
But abstract, generalised ways of doing things obscure the concrete case. Instead of thinking in local terms, I have to learn the generic term and then understand how it will map to my particular problem.
Even if you support consuming UBL or an other HTTP like format or anything really, tracking expenses will continue to be a Hard Problem (tm).
I ran expenses for a fairly large producing organization this summer. I got large stacks of unorganized and under-descriptive receipts every day. Including receipts from flea markets, amish bakeries, and more. Not to mention PO purchases, check requests, petty cash withdrawals, partial returns, returns to cash, and more.
No matter what, more than an automaton, you need someone who understands the business process. You need someone who can look at a receipt and not only know how much was spent and on what SKU, but what that actually item is for, and if it's a valid expense.
I ran expenses for a fairly large producing organization this summer. I got large stacks of unorganized and under-descriptive receipts every day. Including receipts from flea markets, amish bakeries, and more. Not to mention PO purchases, check requests, petty cash withdrawals, partial returns, returns to cash, and more.
No matter what, more than an automaton, you need someone who understands the business process. You need someone who can look at a receipt and not only know how much was spent and on what SKU, but what that actually item is for, and if it's a valid expense.
It is important to have a contact who will make sure that invoices are approved and get paid in a reasonable time. If not they have a tendency to go missing. The important thing is tracking what has been authorized for payment. Without solving that a protocol would risk being just another black hole where unpaid invoices languish.
Instead build something that tracks approved invoices. When an invoice is approved the vendor gets an email asking them to fill in a form, entering all the data from the invoice. Include a big "pay me" button at the bottom. Don't make the payment until the data is provided.
Instead build something that tracks approved invoices. When an invoice is approved the vendor gets an email asking them to fill in a form, entering all the data from the invoice. Include a big "pay me" button at the bottom. Don't make the payment until the data is provided.
No HTTP style standard, but a XML standard http://en.wikipedia.org/wiki/Universal_Business_Language
This is something that has ramifications everywhere. For example it drives me nuts that I get handed pieces of paper with every purchase but stuffed if a supermarket till will mail me a reciept. Want to drive adoption of reward cards(+) at your supermarket? Allow every holder to get downloads of their spends. Now hook that in for all your partner orgs. We will happily throw away out privacy for that !
(+) and for the love of Zeus, stop calling it a loyalty card. I am loyal to family, friends and the Queen. Your coffee shop does not even rank.
(+) and for the love of Zeus, stop calling it a loyalty card. I am loyal to family, friends and the Queen. Your coffee shop does not even rank.
The term "loyalty card" is descriptive, the goal of the card is to increase your loyalty to the store by targeted marketing.
I'm surprised that your supermarket actually uses that name because it should twig anyone who thinks about it that something ain't quite right. The stores I know all call them discount cards.
I'm surprised that your supermarket actually uses that name because it should twig anyone who thinks about it that something ain't quite right. The stores I know all call them discount cards.
Try Costa Coffee, The poor serving staff are so used to "do you have your loyalty card?", its like a tape playing.
Sadly I am loyal, like a heroin addict is loyal to his dealer.
Sadly I am loyal, like a heroin addict is loyal to his dealer.
I like to pay in cash and get handed a receipt on the spot. Because, frankly, what I buy at the supermarket is nobody's business but my own.
If a store has a "reward card," (i.e. they have an extra markup which you can remove by selling them your personal information), I shop somewhere else.
If a store has a "reward card," (i.e. they have an extra markup which you can remove by selling them your personal information), I shop somewhere else.
I've worked on this problem for the past ten years. The solution would be to build line item data into the payment networks according to one standard or another. Unfortunately, the established payments companies have prevented startups (such as mine) from doing so because it's not worth it to them. They make a fortune from their existing, aging infrastructure. So we're stuck with the old networks until the courts fix the mess of unconstitutional laws they've set up to guard their profits.
Line item data is the holy grail for a number of players in the payment space. The merchants are understandably guarded about sharing this information.
There is going to be invoicing protocol in the next Bitcoin version. Let's see what kind that will be.
Other than that, money before Bitcoin has never been a communication protocol, but a centralized database where the database keepers benefit from network effects & locking in the customer to that specific database. So it is pretty obvious IMHO that no good protocols have been developed around it.
Other than that, money before Bitcoin has never been a communication protocol, but a centralized database where the database keepers benefit from network effects & locking in the customer to that specific database. So it is pretty obvious IMHO that no good protocols have been developed around it.
What if you use MailGun or Sendgrid to receive forwarded email, then use your scripts to parse the invoices customers forward you, and offer the data back in various formats like Excel, Quickbooks, and JSON?
I would pay $30/month for that. Even better if you wrote a Context.io filter to automatically start forwarding invoice-looking things to your system.
I would pay $30/month for that. Even better if you wrote a Context.io filter to automatically start forwarding invoice-looking things to your system.
A standard for embedding the document data inside a PDF would be useful. Make it machine and human readable.
a lot of different standards cover it, this is the one the UK's HMRC require submissions in - http://en.wikipedia.org/wiki/XBRL
This sounds interesting for Open Transactions or Ripple.
The same fragility problem that REST solved remains running rampant in how businesses invoice each other.
What if each business allowed you to provide an end point to which they would POST when an invoice dropped, using a free and open standard? Wouldn't this cut an accounting departments' head count down significantly?
The lack of adoption to take seems like the answer to my question...
As a SaaS business, why would I build an end point when I can sign up for recurly or similar and just auto email invoices?
As a small business receiving invoices, this is something that takes 20 minutes a week to type in.
As a medium to large business, it gets to the point where I have 50 invoice scraping scripts and am feeling the pain. I guess at this point the answer is to "hiring another book keeper" but it bugs me that an open standard and a simple POST would automate the whole shooting match.
Are other businesses doing this "right" in a way I've missed? Is there an opportunity here for software to eat a bit more of the world? Perhaps simply publish an open source standard and see if people run with it?
[EDIT: Tried to use less words to explain the problem]