Accounting’s Data Problem
…if you ask what the team needs, they may say more accountants. At Numeric, we’d say they need a proper data platform.
Why work on accounting? It’s a common question—one that we get all the time. We’ve built a product-centric company with a strong engineering culture, and accounting is not typically thought of as a domain which attracts top minds for solving problems in software. Yet we remain laser-focused on accounting.
In speaking with other engineers, an important part of explaining what we do is setting the baseline for what the state of play is today: the work of accounting is substantially, frustratingly, unsolved and manual even though every company has to do it. What you might assume is fully automated often isn’t. Here's a simple example:
A software company “Todo List Apps, Inc.” signs a 2 year contract in January with AWS for $240k worth of reserved EC2 instance capacity. It’s a win-win: TLA saves 40% on their compute costs, and AWS gets the full cash amount paid upfront.
From an accounting standpoint, it would be wrong to say “we burned a great deal of money in January but now we’re profitable”. The goal is to approximate the profit function of the business, and to be able to answer: if I put a dollar into this business, will more than a dollar come out? So we must normalize for time. In the case of this expense we’ve paid upfront for, the logic is fairly simple. Instead of saying we spent $240k in January, we consider that we’ve converted one asset (cash) into another asset (a pile of service owed to us). We then “spend” this asset evenly over the course of 2 years, using about $10k worth of EC2 credits a month.
The actual math here is dead simple: take an amount, and spread it out evenly over the length of the contract. There are corners, sure, but addressing things like partial start/end months or a leap year are fairly everyday problems in programming. In spite of this, automation plays only a small role in the way companies of all sizes solve this today (spoiler: with manual work and Excel). Here’s what it looks like.
At month-end, Angela on the accounting team has a task to search their accounting software for large expenses from the month to see if any look like they are not one-off expenses. Until treated otherwise, the system will assume they are. When she finds one for $240k, she knows it’s likely a contract for a year or more, not just for January. She logs into a tool like Bill.com, or Ramp, or Brex, or Zip, or otherwise to find the original contract. She downloads the PDF.
She opens up the Prepaid Software Expenses Excel file that her team shares and keys in the details of the contract to one tab—the vendor, the start of the service, the end, the total amount, the department that incurred the expense, and more. Then, there is another tab to project the change in the asset’s value over time. That tab contains a formula that looks something like this:
This formula drives the math for how they amortize, producing the change in each prepaid software contract per month. It will have hundreds or thousands of contracts represented (both present and past).
She notices the row hasn’t been picked up and realizes she needs to click and drag a cell down one row to get it to include the newest row in the calculations. Once she’s done that, she goes to the “Export” tab which adds up all the deltas across every contract to produce a single number for the month: $117,320.29, representing the total usage of paid-upfront software services at the company. Later, once all such contracts have been entered, she’ll export the CSV to then import into their accounting software (e.g. Quickbooks or NetSuite). This simplified, aggregate number represents the ending result of this process. If something new comes in, she’ll delete the transaction, fetch the contract, update the spreadsheet, check the amortization, and upload a new CSV with the latest total. And if there is an error, it’s likely to burn days of her time as she hunts down the cause through the gargantuan file.
In the absence of a better system, these types of Excel files serve in place of a full software stack. In this instance, the file is the database for this contract’s structured data. It serves as the business logic and handles transformation of the values. It serves as an integration, producing a CSV for export. Teams will have various methods for version control of the file and some light checks for correctness. Unfortunately, this creates immense manual work and innumerable errors due to subtle mistakes, lack of tests, denormalized data, and out-of-sync state.
This tedium is not just performed for prepaid software. Next, Angela will move on to the file titled “Lease Schedules”, which contains the upfront paid asset representing their right to their office spaces, and the amortization math to use the space over the length of the lease. Physical assets, like their employee laptops, will also depreciate in a remarkably predictable fashion, yet those spreadsheets will require a manual export each month as well. Their revenue may look similar—just imagine the EC2 scenario from AWS’s point of view. If they have loans with banks, what they really have is a lump sum obligation and a very predictable schedule on which it will be amortized to zero. And so on and so forth.
Toward the end of all this, error checks and cross-referencing are done by the team to spot mistakes and missing information. When transactions are erroneous or incomplete, the cost to address the issues will heavily depend on how quickly (Days? Weeks? Months? Years?) they identified it. Meanwhile, the CFO, the CTO, the finance team, budget holders, and possibly investors are awaiting the results because the output of this careful dance is the financial data of the business. There are decisions, adjustments, and insights to be gleaned from this data.
This is a universal, though hardly comprehensive, story about how accounting is done in companies big and small. Manual work is immense, and accountants spend the majority of their working lives collecting information, moving data, running calculations, and uploading CSVs. Spreadsheets power this world. It’s a lot of data work, and the accounting role can be a draining job in a constant state of catch-up—most acutely observed during the month-end close.
If you ask the team, they may say their hardest problem is hiring—the field of accounting, after all, is not growing. In fact, the talent pool hasn’t kept pace while challenges have mounted. As the volume of data, the number of systems of information, and the scale of the business increase, things inevitably become more complex. Part of this growing pain is due to the explosion of data and systems since the turn of the millennium (which their accounting software predates), and another part stems from the expansion of regulations like Sarbanes-Oxley (2002) and the Accounting Standards Codification (2008), both created in response to catastrophic fraud and error. The job for many accountants is unrewarding and the field can be a difficult one to enter, leading to the state of under-supply today.
So if you ask what the team needs, they may say more accountants. At Numeric, we’d say they need a proper data platform.
Our direction as a company has been heavily informed by a few strong beliefs. First, when you have manual, repeated work, errors are inevitably entering the system and creating bad data. Second, if you have a data problem, it’s usually a bad idea to try and patch said problem downstream. Such issues proliferate in a way that can be exponentially painful, and building on top of bad data leads to predictable outcomes. If you can fix it at the source, you should. Third, accounting is sitting on a massive data problem and the situation cries out for good engineering and product.
We believe the future of accounting is one in which we’ve been able to effectively lift everyone’s role one or two layers of abstraction up from where it is today. The integration, movement, and matching of data should be done by computers. The math, projection, data pipelining, simple analysis, and error detection should be done by computers. Even the interpretation of the events, and the first take on the correct accounting treatment of things can now be done with computers. The current state is one in which the team building and owning the dataset—the accounting department—is so busy and undersupported that they are always playing catch-up. Meanwhile, leadership and decision-makers only gain access to a fairly shallow data set, limited in its usefulness because its accuracy is questionable, its depth is limited, and the tools available to use it are disappointing.
By freeing people from moving data, manually error checking, spot-testing Excel files, and more, we can raise the ceiling for how good outcomes can be. Getting the information and producing trustworthy accounting books should be just the first step toward an overall operation that uses the financial data of the business to drive strategy. These problems are holding back companies at large. They make life hell for accountants. And they are solvable. That’s why we’re building Numeric.