No man’s land of blockchain accounting

I recently had a chat with a prominent character in the Web3 space who said doing proper accounting is difficult.

• Paying hundreds of members of a DAO for participation in crypto currency?
• Keeping track of contributions or selling fractional ownership of NFTs?
• Uncounted cashflow from unknown addresses?

While cashflow is great these are literal nightmare scenarios for any accountant — even for the ones specializing in Blockchain startups. An additional hurdle is legal challenges — who do these addresses belong to? Are they human or corporate entities? And in either case — where, in what jurisdictions are they situated? These questions determine the VAT-level and KYC requirements.

Blockchain transaction invoicing

Let’s design a minimum viable product — what can we do to address all these issues while implementing a Web3 native solution which ‘gets out of the way’ from focusing on your cool DApp?

Logic

The first component would be invoice generation. Talk to any accountant — what they expect as the input for their work are the invoices. Perhaps a monthly report, especially aggregated by counterparty, would suffice, but ideally we are talking about oldskool invoicing. In the context of a smart contract or a DApp it could very well be a “micro-invoice” — think, a JSON file containing the recipient, the article and the sum. It would be generated whenever there is a successful transaction, perhaps even from inside the smart contract as a ERC- standardized event.

Second component is fiat. The poor accountant, living in an ordinary world, needs to report data in normal currency. So if the transaction was conducted in some obscure ERC20 token there needs to be, on the invoice, information about the FX rate. Ideally the micro-invoice contains the amount in USD (or USDT) — this can even be fetched from within the smart-contract through an oracle.

The third component is KYC. While the laws on that differ greatly from jurisdiction to jurisdiction, whether you are dealing with a company or a private individual and the invoiced amount, the safe approach would be to register all entities you are dealing with. This means keeping a list of companies and their jurisdiction (country) in a separate repository. It makes sense to also think about rejecting or refunding transactions from unknown addresses or at least lock the amount until it is clear what are the missing pieces (article, amount, recipient type, recipient info).

Storage

For the sake of GDPR and similar requirements, it makes sense to obfuscate counterparty information. We should be able to tie invoices together with recipients but not inform everyone about these details. Companies can decide themselves whether they wish to broadcast and claim a wallet address as their own. So, a key component is a public private key pair to encrypt and decrypt this information at the right junctions. The access to the key can then be provided to the accountant.

Integration

As for integration, the difficulty is that due to legal and cultural differences each country has their own favorite accounting software. Also, while the tax authorities might have API endpoints for submitting tax information the overlap is not complete and standards not universal. The solution could be to integrate with software automation products such as Zapier — thinking being that these products are already used by enterprises, known by digitalization consultants and have connectors for accounting products already developed.

What about payment providers?

Using payment providers/processors to accept crypto on your web page and then immediately have them wire you fiat is an anti-pattern. Yes, there are many organizations providing exactly this service but ultimately it is unnecessary. It is just another leech for the Web2 world — yet another service provider among 110 SaaS products enterprises use on-average.

Blockchain provides the full stack: data, logic and payments. It already enables receiving funds, you can use logic (DeFi) to swap currencies, accept stablecoins directly or hold assets in your wallet as long as needed. Accountants care about the transaction but after the fact it is a separate exercise to value the company’s assets. These two activities can be split: for the monthly/quarterly valuation of assets it is not necessary to receive fiat in the first place.

Secondly, by having a payment provider accept crypto on one's behalf makes it impossible to really capture the value provided by blockchain. By owning your own smart-contract the business could issue NFTs or utility tokens to increase their retention. The next step would be to engage users and partners with more options besides payment — record data points using smart contracts, show information from the supply chain to further transparency or offer new business models entirely. Some of these use-cases can be seen in our gallery at List of flows (toolblox.net). None of these options would be available if companies obfuscate blockchain by using payment providers.

Ada

In the course of last few months we set out to create exactly this — a simple invoicing engine for blockchain businesses. Ada is a tool which helps any smart contracts generate and send invoices. It monitors the chain, registers incoming invoices, generates PDFs of them and sends them out. It also provides a neat dashboard to review them and conduct reporting. More details soon!

Beta version of Ada is available TODAY at https://ada.toolblox.net.