Update: There's now a Finnish e-receipt standard, so it made this project obsolete. The e-receipt format is open and publicly available. It's mostly based on finvoice format. It's called eKuitti in Finnish. It doesn't meet all the requirements mentioned here. But it's still the best change to get eReceipts actually available in Finland.
It seems that many people think only about email receipts, when talking about electronic purchase receipts. But that's only a very minor part of the whole potential e-receipt ecosystem. I'm assuming everyone reading this document is aware of the importance and potential use cases, which do not usually come into mind of most consumers.
The goal of this project, is to define common representation for e-receipt data. Without common standard, e-receipts are just like most of other data in proprietary formats. Requiring expensive and error prone data format conversion and mapping from format to another. This greatly adds expenses and make the systems very brittle and hard to modify as well as present the stakeholders with annoying vendor lock-in.
Receipt data structure should be nested, but in a way, that it's trivial to represent it in JSON, XML and the good old CSV. There must be header, header extensions, receipt items, and item extensions. I've found out that many standards claim to be extensible, yet usually do not allow it after all. As example I could mention XML formats with way too tight schema. Just go and extend it and it fails. Correctly designed data format, does not fail, if it's being extended. Extensions just need to be such, that those are backwards compatible and nothing breaks if the new extensions are ignored by older implementations.
I'll be providing example data structures written as Python object, and then exported from that to formats mentioned earlier. Unfortunately CSV doesn't provide any standard for nested structures, so I'm taking suggestions how to deal with those. Of course I have long experience from different options used by multiple systems so far, but it takes some consideration which is the best approach after all.
I've posted earlier about my integration solutions made so far, and extensive support for different transports. Because there is standard data structure, it can be practically transported over any transport method. But there will be a standard REST implementation which also includes URL paths, parameters and responses. This is the method which should be used with all modern systems. I know there will be systems using FTP and CSV files, but that doesn't change anything for newer implementations.
There must be possibility for additional extension slots for national and vendor specific extensions. As example, one country might require digital signature on every receipt. Great, no problem, just create national standard extension format for it, and put it in. As well as I've seen some systems which require sub second time stamps for every item on receipt for linking read bar codes to video recordings from store etc. No problem.
Some data protection directives clearly tell, that customers should be able to check their own data, and download it. But what's the use, if there's no data standard? Therefore common e-receipt standard is absolutely vital. If there's no standard, it's just like scanning paper invoices, it's completely insane thing to do. But just has to be done, because there's no better common option available. Don't laugh yet, just read the next paragraph.
I've done a few requests for personal data? What did I get? A huge thick stack of printed screen captures from DOS / Unix terminal application. That's totally useless format for any further automated processing or analysis.
I'm aware that some vendors & associations claim that there's an existing e-receipts standard. I asked them if they would send it to me, so I can read it. But they weren't willing to send it. What's the use of secret standard? Usually it simply means that it's not available to consumers nor smaller companies at all, basically making it meaningless and useless.
In Sweden, it's legally required to store receipts in electronic format, except there's no exact standard format defined. So processing any data further will be hard. There has been similar discussions in Finland too.
A few keywords: ekuitti, sähköinen kuitti, e-kuitti, e-invoice,
einvoice, e-invoices, invoices, 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, open data, mydata, personal data, downloading, downloadable, analysis, analyzing, omadata, yhteensopivuus.