It’s been a while since my last post, so I thought today would be a good time to share information on one of the projects that’s occupied a lot of our time over the past few months: our new accounting system.
As our US customers will know, we just recently passed the deadline for filing US income taxes. While BlockTrades itself is a Cayman Islands company which doesn’t get taxed, its shareholders do have to pay taxes, including taxes on profits from the company. To compute those profits as efficiently as possible, both now and in the future, we decided to create software capable of automating all the bookkeeping for our company as well as software for catching accounting problems and mistakes by third party vendors.
Unlike most companies, BlockTrades deals exclusively in cryptocurrency, not only with its customers, but also with its external contractors. BlockTrades doesn’t even maintain a bank account. In the cases where it does need to pay someone in a fiat currency, it works with an external payment agent that sells off the cryptocurrency for cash to make the final payment.
As a result, almost all incoming payments and expenses for BlockTrades are recorded in blockchain records that can be analyzed via software (except for deposits/withdrawals and trades on external exchanges, but these records can also be imported as computer records). This means that we don’t have to manually enter things like check payments into an accounting package: any payment we make or receive via any of our blockchain wallet is automatically accessible to our accounting system.
In addition to the accounting research involved in developing our new accounting system, it also required a fair amount of software to be written. Here’s some of the software pieces we had to build:
The most difficult work was to develop the blockchain scanners. We needed a scanner for each blockchain we operate with in order to import transactions from the wallet into our common ledger format. This job was particularly challenging for graphene-based blockchains such as Steem and BitShares because of the large number of operations. For example, Steem not only supports payment transfers, but also author rewards, curation rewards, mining rewards, SBD to Steem conversions, and interest from SBD, just to name a few. The scanners also have to account for blockchain transaction fees. We already had partially-written scanners that are used by our trading system to recognize customer payments, but adding support for the all extra operations and converting the data to a common format was a lot of work.
A translator for each exchange we operate on, to import deposits/withdrawals and cryptocurrency trades. Different exchanges have different formats and they don’t always even supply the same data. One of the more difficult aspects of writing a translator for an exchange is to be sure you correctly account for the trading and withdrawal fees they charge.
We developed software to cross-check transactions made on blockchains versus the import/deposit records from exchanges (for example, this code detects when an exchange failed to credit us for a deposit or debited us for a withdrawal that never really happened)
Virtually every blockchain wallet can report the current balance in the wallet. But many blockchain wallets don’t report old balances, especially wallets that support more complex operations (e.g. BitShares, Ethereum, Steem) to name a few. But many financial calculations require the ability to report an account balance at any given time.
Mark-to-market accounting is useful for computing trading income when you are doing large numbers of small trades like our web site performs daily. With mark-to-market accounting, instead of doing a capital gains calculation for each trade, you just compute the net value of your holdings at the beginning and ending period of time (offseting the result by any funds transferred in or out of the mark-to-market accounts). Our mark-to-market accounting code computes profit over a period by computing the value of each of the hot wallets connected to our trading site at the beginning and ending of the specified period (using the balance computation code described above to get the balance at each time point and historical pricing information for the coins) and subtracts inflows/outflows due to operating income and expenses.
For our long term holdings, instead of doing mark-to-market accounting, we perform more traditional capital-gains based income calculations in order to defer the point at which we need to recognize income to the time at which we realize the gain by selling the asset. We developed a capital gains calculator that performs lot assignment on trades so as to minimize realized gains for trades made in our investment wallets. The capital gains calculator also computes the gains after the lot assignments are made and convert these gains into our “functional currency” for tax reporting purposes (US dollars).
We developed a web-based front-end to our accounting system that can show things like balances over time in coin amounts and equivalent USD value as well as daily income from different sources such as mining, delegation, etc.
Finally, we wrote code to check all our trades from our web site versus the records in our blockchain wallets and to compute unrealized gains and cross-check our financial results against a fully mark-to-market based accounting.
At this point, most of the work above is done, although we do have a few things to finish up when we get some time. It took us a long time to develop this system, but it gives us a tremendous amount of confidence in our financial reporting to have a robust system in place that’s not subject to the amount of human error involved in a standard accounting system. And while it’s not really appropriate for sale at this time since most companies still do most of their transactions via fiat payments, we will be keeping an eye out to see if there’s a point at which we may want to commercialize the software beyond our own internal usage.
