
Ask HN: Why aren't there HTTP style standards for invoicing things? - johnnyg
I manage expenses for my company on an AMEX card. People I work with that want to expense something over X amount come get my card, make the purchase, return the card and forward the invoice. Each invoice is a unique snowflake. Some contain data that can be scraped, others direct to you a website which may or may not be able to be scraped. Design changes break the scrapers. They may or may not support a billing email and if not, things get even more muddled.<p>The same fragility problem that REST solved remains running rampant in how businesses invoice each other.<p>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&#x27;t this cut an accounting departments&#x27; head count down significantly?<p>The lack of adoption to take seems like the answer to my question...<p>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?<p>As a small business receiving invoices, this is something that takes 20 minutes a week to type in.<p>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 &quot;hiring another book keeper&quot; but it bugs me that an open standard and a simple POST would automate the whole shooting match.<p>Are other businesses doing this &quot;right&quot; in a way I&#x27;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?<p>[EDIT: Tried to use less words to explain the problem]
======
jaegerpicker
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.

~~~
protomyth
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.

------
johnorourke
ANSWER TO YOUR GENERALISED QUESTION:

cXML [http://cxml.org/](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/](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).

------
walshemj
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](http://en.wikipedia.org/wiki/Electronic_data_interchange)

EDI was live back in the early 80's in the UK

~~~
harrytuttle
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 :)

------
jta
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](http://en.wikipedia.org/wiki/OIOXML)

------
kephra
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.

------
rektide
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/](https://payswarm.com/specs/)
[http://digitalbazaar.com/payswarm/](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/](http://www.w3.org/community/webpayments/)

------
larrys
"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.

~~~
johnnyg
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.

------
xhedley
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.

~~~
quantumpotato_
[http://tradeshift.com/invoicing/](http://tradeshift.com/invoicing/)

------
koudi
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.

------
jacques_chester
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.

------
cdcarter
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.

------
7952
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.

------
martyn80
No HTTP style standard, but a XML standard
[http://en.wikipedia.org/wiki/Universal_Business_Language](http://en.wikipedia.org/wiki/Universal_Business_Language)

------
lifeisstillgood
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.

~~~
Amadou
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.

~~~
lifeisstillgood
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.

------
thinkcomp
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.

~~~
tazzy531
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.

------
jerguismi
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.

------
nthj
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.

------
tonyedgecombe
A standard for embedding the document data inside a PDF would be useful. Make
it machine and human readable.

------
phpnode
a lot of different standards cover it, this is the one the UK's HMRC require
submissions in -
[http://en.wikipedia.org/wiki/XBRL](http://en.wikipedia.org/wiki/XBRL)

------
quantumpotato_
This sounds interesting for Open Transactions or Ripple.

