Claude Code for Financial Planning – Top-Down vs. Bottom-Up Approach

Claude Code

Late last year, I tried using Claude Code to assist with some financial planning. This was driven in part by a planned move to a new city and understanding the corresponding cost of living.

I explored a few different approaches in parallel – a top-down type of workstream and a bottom-up workstream.

In this context – a top-down approach means larger scope: effectively I compiled all of the financial statements and transactions from a given period of time, say the last 3-5 years, and then used Claude Code and other tools to actually parse out the transactions, compile them, categorize them, and analyze them or enable my own analysis of them.

I tested a few different approaches that uses this sort of top-down workflow.

The original overall approach or pipeline was:

- Create an overall plan or outline

- Compile / download financial statements (PDFs)

- Drop into a local folder and have claude code work with them end to end:

• Provide initial context and refine plan using Claude Code’s plan mode

• Convert each PDF into Excel or csv

• Parse out the transactions

• Aggregate the transactions into a single Excel or csv

• Categorize the transactions

• Perform follow-on analysis

• Iterate

After a few hours it became clear that parsing out transactions from PDFs to Excel / csv is deceptively challenging (even for Claude), particularly when working with different data sources. So I replaced that specific step with using a third-party PDF to Excel conversion tool that I already had access to and was both much faster and more reliable.

Otherwise, the overall top-down approaches were the same.

My findings from the top-down approaches were as follows:

• First of all, handling large scope to start can be overwhelming in terms of the amount of the amount of necessary code (and of course corresponding context windows)

• Second of all, because of the volume of code and data corresponding to the scope, the human testing costs become much higher

  • In other words, the realm of possibilities of things that can go wrong are much broader, require more rigorous testing and the testing is more time consuming to perform

  • Unless an issue is glaring or there is some clear prioritization that can be done – for example identify what the largest transactions (such as rent payments), the transactions require a fair amount of individual review

  • However even when prioritizing these things there are all sorts of nuances that can get introduced – for example transactions being combined together, or amounts being off, or occasional exceptions that are difficult to spot (e.g. imagine a paycheck and a bonus being combined together or a rent payment being combined with a security deposit or a move from one apartment to another leading to different rent costs, etc.)

  • Oftentimes the context is situation-specific as well which makes more automated tests or handling this via the planning phase more difficult

• Third of all, in terms of the reliability and accuracy of the code – the top-down approach is decent at creating estimates but if exactness or precision is necessary, it is of limited utility as it would require a fair amount of manual quality control and testing. This may be okay as a starting point but usually requires complementing with other approaches to get more precise data

The bottom up approach

Given the limitations of the top-down approach, the question came up: is there a complementary or perhaps alternative approach to the top-down process that focuses on a smaller scope?

For example, starting with a specific category of spend, mastering that and then repeating the process for other categories.

The business analogy I would use here is how Amazon focused on a specific product category to start (books). There are similar best practices when starting a business – specifically to focus on an underserved niche rather than trying to explore too large of a market and risk more competition, expensive customer / user acquisition, etc.

So the bottom up approach has the benefit of targeting specific categories one at a time (e.g. rent, grocery spending). This in turn involves smaller volumes, similarly structured transactions and less corresponding complexity so it involves less code, simpler testing, less cognitive load and greater transparency into both the data and the code.

This has been my experience so far.

To summarize: the key benefit of the bottom-up approach is simplicity. Less categories, smaller transaction volume, less things that can go wrong, and less things to consider at any given time.

Now compare that with the top-down case where you have many statements across multiple categories. So you have a much larger volume of transactions of different types. You have different types of data structures for each. You have different types of ways in which things are expressed and net of those considerations there are many things that can go wrong potentially at each stage of the process, particularly when you’re parsing, aggregating, and analyzing the transactions.

An Open Question – Building Up to Complex Use Cases?

In addition, there is an additional potential benefit for more complex systems with a large volume of categories. My hypothesis is that if you build it up from the bottom step-by-step, category by category and each category is sufficiently constrained, over time you may be able to create an orchestration agent to actually coordinate each of these as if they were separate services.

For example you can have a grocery purchase analyzer as one service.

You can have a rent payment analyzer as another service, a medical appointment analyzer, a transportation payment analyzer, and so on.

You can do something similar for basically every category of items that is sufficiently standardized or constrained. Then, as you (and the system) develop a strong understanding of these you can then potentially automate the system entirely.

I need to pressure test the feasibility of this by running some experiments, but early indications are promising.

Conclusion

Overall, Claude Code has been very helpful in assisting me with financial planning and other use cases. So far – the top-down approach has been preferable to get a decent estimate of overall spend while the bottom-up approach has shown the most promise when exactness and detailed results are necessary.