The current push towards creating some kind of standard for electronic invoices (which would allow for a standardized data package to be transformed into QR) is called ZUGFeRD.
The Zip(?!?) Containing the specification can be found here:
This is a push towards adding data to the PDF Metadata that would allow for digitally reading of that electronic invoice by financial systems.
The current problem, from my reading, is that there is not enough players that see a positive ROI for implementing this standard on a wide scale on systems where it would make sense.
As for paperlessness: I routinely pay my cellphone bills by scanning said QR code from computer screen.
If you end up in a dispute with your phone company, you are putting yourself at their mercy. It's waaay easier to fight a charge you haven't paid yet, then to recover money you've already paid.
I've gone through hell because of this.
 Oh, I guess you mean in the case of a regular payment of an uncertain amount, like a mobile phone bill. I use a pay-as-you-go plan where a direct debit takes a fixed amount out of my account each month, and if I overrun it then my phone stops working until I pay more. I'd definitely think twice before setting up a DD for a mobile phone contract.
On the other hand I know many people who like me do not use direct debit for "unpredictable" things like cellphone bills. Most other payments can be automated by standing orders, what sucks that even when your monthly phone bill is essentially constant you cannot do that as our cell operators generally assign distinct payment reference for each monthly bill.
Standard description : https://en.wikipedia.org/wiki/Short_Payment_Descriptor
One thing that fascinates me is contrast between european giro banking systems and ABO in particular (where account number is just an ID/address and has no security implications) and checking account based system used in US where everithing seems to be somewhat backwards from what would make sense.
QR codes were originally invented for inventory tracking. This is just an extension of that.
(See Chapter 9).
QR can store binary data. Something like BSON would make a lot more sense, given the tiny amount of storage in a QR code. Even ASN.1 seems more appropriate than the silly data->ASCII->ASCII-structured-format->binary encoding that's going on here, and admittedly in a lot of other transport formats too.
But FWIW, it never got popular. I guess you can tell by the design of the website.
 http://www.bezahlcode.de (In German only)
Edit: It is actually not encoding all data of the invoice, but only the bank details needed for the transfer.
Rest assured that these petty JSON, vCard or the like ideas have little chance to work in real life, specifically if you need to compress invoices into the space limitations of QR codes... Real life B2B invoices are much more demanding.
When it comes to payment information, that is much simpler to solve. You don't even need to QR encode that, relatively simple forms with human readable numbers can be read by modern smartphone banking apps. I have two different installed (two different Swedish banks), works with most of the invoices I get home. The few that still come on paper, that is.
I think the Json format is cool. Qr codes as a representation should be one way of sharing it.
Having one of the worst tax system in the world I'm surprised that somebody had the idea to implement this mechanism.