E-Receipt, what's holding it back?

Post date: Apr 12, 2014 6:43:24 AM

Hi. I started to map out the current situation of the e-receipt. As far as I can conclude, there's no commonly usable standard for it. I'm now wondering if you do know open widely used or usable free ereceipt standard? If you do, please let me know. If you're also receipt guru in your country, I might be interested to hear more about you. I naturally know the requirements for Receipts in Finland and in EU area, but outside that I haven't been working too much on the topic. Of course finding out requirements for US and states should be quite trivial.

Let's now skip the technical terms. What are the actual reasons, which are holding e-receipt back? I have seen several studies to say, that at least 85% of consumers would love to get e-receipts instead of collecting that annoying chemical paper trash in their wallets.

After quite quick analysis I came up with two reasons.

1. Identifying the customer

2. Lack of standard

As integration expert, I would say that fixing the latter is quite trivial in technical terms. We should form a expert group to create versatile integration standard. I've been doing hundreds of integrations yet, each system handles receipt data differently. It's really annoying. There should be one widely used standard. All those discussions is the total price of the row item price times the quantity, and what if it's return row? Should the quantity be negative, should the price also be negative, or is there some kind of separate return flag. Or maybe the whole receipt is void receipt and the information if it's actually negative or positive row isn't even directly available from any of the fields of this individual record. How are discounts handled, especially subtotal discounts etc. I have very strong views how those things should be done, so it's efficient, simple, yet versatile enough.

Is there any interest for this kind of project? I can create community and wiki for it, if there is. Even better, if there's already existing (free & open) standard which I'm just not aware about, please let me know.

I already created Google+ community group e-receipt professionals SIG for potentially interested people.

I also created a little e-receipt project page for this idea, I'll be crafting it when ever I have time and receive feedback from different sources.

National situation in Finland:

In Finland retailers are by law, required to offer an receipt for purchase transaction. E-receipt is viable option, but there's no standard for it. There has been some discussion that e-receipt should be forced by law. Also making it possible for tax authorities to easily process receipts. But if there's no common standard for it, it's impossible to start using such system.

Quotes from e-receipt SIG discussions (Replies written by me, see original questions in the SIG). I'm again explaining why the message format standard and data structure is so important:

Two problems mixed? Yes, that's why I labeled those separately as two different problems.

I'm aware that those are two separate problems and there will be two separate solutions. 1. Is something which is the harder part. I don't mean that it would be technically hard. But it needs to be very quick and reliable. Nobody wants to write e-mail addresses at coffee shop during rush hour. 2. Is totally trivial. 3. One thing which limits the adoption is lack of standardization. That's why I'm especially addressing it in the SIG. If there's commonly used standard, it's much easier to adopt using it. Closed POS vendor solutions just won't work. We've seen major well funded players like Nokia completely failing to deliver simple service like this.

Without proper standards, it's just way too much for individual shopkeeper and entrepreneur to pay for something like 5-10k for simple integration stuff like this. But that's what it easily ends up with everyone using their own custom data formats, requiring complex and slow (aka expensive) mapping, and different transports (sftp,ftp,http,email) etc.

Btw. I've done 100+ integrations and I've got 15+ years of experience from Retail, POS software, solutions and system integration. I'm also very familiar with EDI and European E-invoice standards. Which are just bit too complex for easy adoption for most of smaller players.

Why is the API standard and message format so important? Can't we just scan the paper receipts or grab the data going to receipt printer?

Yes, or you could use printer driver which forks the data stream. But those are all lame solutions, because the printed paper version doesn't anymore contain information, which could be useful for automated processing.

When ever I'm doing integrations, I'm very carefully considering the balance when to deplete information. Depleting information can make things look very easy and simple, until you'll find out that the process requires the data you happened to deplete in the very beginning of the process.

As example, you have receipt with 100+ rows, and tons of different items. Could you please tell me what's the tax class or tax rate for each individual row? No? Darn. That's life. That's exactly why proper XML / JSON standard data structure is required. Electronic receipts in vendor specific or as "printout" formats, simply aren't useful. There should also be CSV format for legacy systems. Many IT guys won't just believe how many systems there are out, which aren't able to handle JSON or even XML.

Think situation when you're filing your travel expenses. Great, you're again playing with paper receipts, maybe photographed, maybe scanned ones. But all together, some vital key information is already missing and needs to be re-entered.

Even if the EDI formats and E-Invoice in Finland are pretty horrible standards, those are yet a lot better than no standard at all.

That's why I'm asking for feedback and wish to form a SIG which would be able to create standard that's freely vendor specifically extendable (!) yet not too complex for software developers to adopt.

The small accounting company I'm using wouldn't understand the JSON / XML, they want everything using FAX.

Well, I completely agree with you. That's just the problem with current e-receipts. But I think I have quite a good views to this subject, because I've been working in this field for a long time. I especially always embrace smaller players and kind of loathe standards made by big international boards. First it takes forever for them to create the standard, and when it's done, it's messy, full of compromises and so complex, it's very hard for smaller players to implement correctly if they bother at all. There has to be easy to use user-interface for the data. Raw data is there for techies, but there has to be also human readable standard representation for the same data. As good examples I could bring up EDIFACT and Finvoice.

NFC application for a store chain.

I agree with you. But main problem is that the field is so dispersed. Without open standard there's a vendor lock-in and you'll have to use 10+20 similar apps. Think about email, if everyone would be forced to use Gmail, because lack of federation.

I know there are NFC mobile apps etc, stuff. But those are practically useless, they require customers to invest in the system, they require shop keepers to invest in the system. As well as the system will be very likely proprietary. Which is of course a bad thing.

Also had many more interesting discussions from different viewpoints about this same topic. Spam issues, why would anyone want e-receipt. Isn't it retailers responsibility to keep receipts. Well it is, but what's the use for you if those are kept by retailer. Which is the current norm, usually they don't provide any way to access that data, etc.

A few keywords: ekuitti, sähköinen kuitti, e-kuitti, e-invoice, einvoice, electronic invoicing, electronic receipt, mobile receipt, email receipt, digital receipt, digital signature, service, site, API, JSON, XML, standard, schema, system integration, point of sale, retail sector, consumers, consumer, service, web site, web service, webservice, business, entrepreneur, european, special interest group, board of professionals, system specialist, European Union, legal discussion, requirements, fiscal, tax authorities, national legalization, laws, law, EU, Americal, global, international, internationalization, standardization, standards, stateful, stateless, adopt, adoption, national needs, extensions, extendable, extended, REST, RESTful, HTTPS, HTTP, flat files, SMTP, multi transport, transports, connection, connectivity, federation protocol, universal, distributed, open e-receipt standard, open e-receipt initiative.