Disclaimer: if you don’t plan to use your money after retirement OR use your financial data to uncover novel insights, please read no further.
Now that we’ve gotten that disclaimer out of the way — people use IRAs because they intend to use their money later, and people put data in databases because they intend to use it later. Around 300,000 people per month search for “Roth IRA,” if you add up all the search combinations, I’m sure it’s in the millions!
And for good reason; intelligent people have caught on. If you can pay taxes before or after growth, it almost always makes sense to pay before the increase since you’ll pay fewer taxes. Sure, paying taxes upfront and seeing a smaller account balance can come with a bit of a sting. But with IRA tax optimizations becoming common knowledge, it’s virtually impossible to ignore. Taxes are almost always higher later in life, making the comparison even more dramatic:
Paying taxes on a growing retirement fund may make you wish you paid the tax upfront instead. Similarly, if you contribute to a Roth IRA instead of a Traditional IRA, you’ll walk away with 14% more retirement money.
Financial business data is another such example that we hear about less often. Relational databases power virtually all business systems. They store the data efficiently and rarely store the same data in the same place. And for a good reason! Engineers developed relational databases back when storage and computation were costly and data models were static. At that time, new transaction record types in ERPs were uncommon (you could call them unicorns). However, relational databases don’t prioritize data access for analysis.
The relational database design tells the story: if you have separate customer and invoice data tables, there’s likely no relationship between them. These two tables are just two disparate sources in their zip codes. When you want to access a transaction, you need to connect those tables with two keys (in this case, a customer ID stored in an invoices table, for example). Each time you want to access that transaction data to use in an ad-hoc report or monthly financial statement, you must recompute the relationship from scratch! That’s a heavy tax to pay for a complex data pipeline!
So why do we do it this way? Because it’s what we’re used to. Is this the best way? Maybe.
Imagine using data for analysis and optimizing your system design for that outcome. That’s why data platforms exist in the first place! For example, here at Leapfin, our Finance Data Platform employs a graph architecture that links all financial records. Unlike relational databases, we explicitly store the relationship between two or more data points (and most objects have way more than two!), and there’s no limit!
I’ve seen similar examples where data tools and reporting layers are built on top of a data warehouse for the same purpose using a different architecture so that the data is related and materialized for consumption later. We do this for a good reason: to enable finance teams to use their data more efficiently!
Much like planning for retirement, it takes some intentionality and planning upfront. But it’s a good idea to take a fresh look at your finance systems stack and redesign it for its intended purpose: generating business ROI with real-time data and paying the least amount of long-term tax possible. Tune in next week when we do a deep dive into the ERP tax, the biggest tax of them all!
