Fava: Unifying account and tree reports into a generalized report system

[Benjamin Debeerst]

Hi there,

I've been experimenting hacking on the Fava web interface in order to adapt it more to my needs. I think there is a possible path to unify the different existing reports into a single more powerful report that could fulfill existing needs while enabling additional use cases. Let me elaborate.

A non-existing view in Fava that I would like to have for my monthly personal income and expenses review would be a combination of Income Statement and Account Report: The former allows to nicely compare expenses against income. But that report unfortunately does not have a time dimension: It only shows the total change in the filtered time range, and it is cumbersome to put a given month into a historical perspective without jumping around with the time filter.

The Account Report can break down changes/balances on a monthly or weekly basis, allowing me to see how e.g. expenses for groceries and shopping of last month compare to how much I typically spend. The accompanying stacked bar chart is a great visual overview, but it only does so for a single account (tree) though. I've seen requests on the mailing list and in GH Issues to have an account report for multiple account (trees) at once, which is what I was looking for.

I've been going through the Fava code to see whether I could hack something together that either adds interval balances (or changes) to the Income Statement or allows Account Reports for multiple accounts. At which point I realized that all tree reports (Income Statement, Balance Sheet, Trial Balance) already _are_ tree reports for multiple accounts - they just calculate a total instead of interval numbers.

At this point I'm wondering whether it'd be worth working on a change where the classes TreeReport and AccountReportTree from src/fava/json_api.py are unified into a single new report class, reporting on a list of 1..n accounts, always reporting interval balances, optionally accumulated. The Income Statement would become an Account Report for Income and Expenses (not sure exactly how Net Profit could be modeled here yet), Balance Sheet an Account Report for Assets, Liabilities and Equity; Trial Balance an Account Report for Assets, Equity, Expenses, Income.

If I want a total for a year or a month, I can select "yearly" as the interval and filter for a year. Or the interval selector gets and additional option "total".

I think this could reduce some duplication in the backend and frontend code while enabling more custom reports and better graphs for the existing tree reports.

Before diving into an implementation and potentially opening a PR, I wanted to hear thoughts from the community and/or maintainers about this idea and possible obstacles that I may have missed. Curious to hear y'all thoughts.

Best,
Benjamin

[Chary Ev2geny]

Hi,

I know this is not exactly what you are looking for, but I was also looking for ways to better visualize beancount data. I just decided to do this in jupyter notebook,  thus having access to all the modern data processing and visualization tools, available there

For instance I have so-called financial overview table (which may be similar to what you are looking for).

For the sample ledger, used in Fava for demo, it looks like this

This is the proof that this matches Fava content

Note, that this report not only shows Income Statement as well as balance sheet information per time period in one table, it also shows, that one explains other. To make sure, that it is possible to explain the difference in the net Worth Change I had to calculate unrealized gains (otherwise it does not come together)

You can then visualize this table like that

Note: that I have chosen to show Income as a positive value, which in my view makes i easier to compare it with expences

[Brian Lalor]

Would you mind sharing your notebook?  I’ve been doing some similar things with Marimo.

— 

Brian Lalor (he/him)

bla...@bravo5.org

[Chary Ev2geny]

Brian,

definately!

I am working now to bring the notebook as well as all the libraries it relies on to the state, where I will think they can be shared with the wider auditory

I am convinced, that using jupyter notebook to visualize beancount data is extremely powerful combination, I am really surprised how this is not a mainstream. 

Plus it is very hackable and easier to understand. So, it is easy to create your own Fava equivalent.  And it is my experience, that for reporting everybody has his own needs always (also in corporate world)

Regards.

[Brian Lalor]

> I am working now to bring the notebook as well as all the libraries it relies on to the state, where I will think they can be shared with the wider auditory
>
> I am convinced, that using jupyter notebook to visualize beancount data is extremely powerful combination, I am really surprised how this is not a mainstream.
>
> Plus it is very hackable and easier to understand. So, it is easy to create your own Fava equivalent. And it is my experience, that for reporting everybody has his own needs always (also in corporate world)

Agreed. If you haven’t checked out Marimo I’d recommend it. Jupyter never really clicked for me, but Marimo has (to the extent my little brain can wrap its head around data and visualization tools like that). They feel more native and portable (being actual Python files). It’d be great to get a library of these going.

[Martin Blais]

+1 for Marimo

Marimo is the right model for a notebook, that is, reactive/spreadsheet-like cells.

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/beancount/21D40603-5253-472D-80CC-E907E014EA9C%40bravo5.org.

[Chary Ev2geny]

Just briefly looked at Marimo.

Looks very interesting indeed! thanks for bringing this up!

P.S.

Maaaan, there is so much things to learn. How to keep up with all of this (especially if this is just a hobby???)

[Justus Pendleton]

On Wednesday, March 11, 2026 at 8:17:42 PM UTC+10:30 Chary Ev2geny wrote:

I know this is not exactly what you are looking for, but I was also looking for ways to better visualize beancount data. I just decided to do this in jupyter notebook,  thus having access to all the modern data processing and visualization tools, available there

I came across your evbeantools a while back -- your beanquery2df is the foundation of many of my investigations -- and tend to agree this kind of approach is better suited for many. It moves beancount even further away from "regular people can use it" and even further in the direction of "must know python to use it reasonably well" but I also kinda feel like that ship has largely sailed anyway. Notebooks are a little tricky to share publicly but still orders of magnitude less work than hacking fava -- and I'm sure Martin would be happy to link to contributed notebooks if people starting making that a thing.

[Paul Schumacher]

Hi there,

Nice screenshot, it looks like you built a "PnL Explainer", which is something I have been struggling with for a few months now, trying to figure out the right way to do this without re-inventing the wheel. There is a thread about this on the Fava github. 

I started out building something like your screenshot in a Fava plugin, but I wanted to breakdown Realized+Unrealized gains per investment, and I'm still trying to figure that out. (sidebar: in the process I also looked at your work, but it seems to do too much for me).

I have tried plugins like Fava Portfolio returns, but I'm looking for something simpler, to look at a PnL difference over a period, next to other income / expenses.

My current conclusion was that maybe unrealized gains should show in the income statement if the dropdown is set to "At Market Value" ? I didn't quite get what the current use case for "At Market Value" on the income statement is.

Best Regards

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/beancount/5f1ce66c-e52a-496c-8bb7-1eadcdfc2a6dn%40googlegroups.com.

[Chary Ev2geny]

Paul,

yes, exactly, the report I showed is inspired by the Gainstrack P&L Explainer, but initially to be able to explain my P&L was the sheer reason I came to beancount  from Gnucash 7 years ago and largely due to this reason I learned python.

I think if you use the  sing_curr_conv tool as a plugin, I see no reason why you would not be able to see the unrealized gains in Fava (I need to experiment with this). However I agree, in order to show unrealized gains, I had to do some changes to ledger (like converting everything to a single currency), so you lose some information (as explain in the Appendix A here). This is because unrealized gains only make sense, when you convert things to some target currency. And once things get converted to a single currency, you have to make some changes to ledger for it still be valid.

  

Any way, whilst the  sing_curr_conv is not perfect (but still shall be workable) to be used in Fava, it fits very nice to be used in a notebook (Jupyter or Marimo, as I yesterday learned). This is because in a notebook nothing prevents you from having several set of ledger entries: the initial one, as well as converted to a single currency with unrealized gains. For me personally I use main ledger for bulk analysis and the ledger, converted to a single currency to analyze unrealized gains, as well as what I call hidden gains

It shall be perfectly possible to use sing_curr_conv to do a breakdown Realized+Unrealized gains per investment (per commodity, I assume).  

Unrealized gains per commodity are encoded in the unrealized gains Income name:

e.g. in this case this is IVV

Income:Unrealized-Gains:USD-IVV -100 USD

 

See example

Realized gains per commodity you will have if you log them correctly 

e.g.

Income:Investment:IVV

 

But I do not think, that it will be easy to do in Fava. Fava is great, but in my view it is much less hackable, whilst the data analysis with pandas is extreamly flexible.  You can effectively extract anything, create any report and any analytics, provided the data is available. And this is what the sing_curr_conv  does. It provides you data (in a form of an unrealized gains account name as well as in a form of the SCC_Metadata). 

[Benjamin Debeerst]

Hi all,

Chary, thank you for the suggestion, the screenshots from your Notebook
look interesting indeed and I'd be curious for a share of that as well.
TIL about Marimo as well.

In my case, my partner is also looking at the reports, so having them on
the Fava instance running in our home network and which is being used
already would be preferable over installing/running/switching to yet
another, separate tool. The upside of remaining in Fava is also that one
can deep link and investigate: "Wait, why did groceries shopping go up
so much last month?" --> Click through to the journal --> "ah sure, I
made that massive purchase for the party" --> "let me add a note to the
journal about that".

Finally though, trying to bring the thread a bit back to it's original
topic: While it is certainly more technically involved to hack on the
Fava source code to produce reports adapted to my personal needs, I was
hoping to contribute back and make the improvement accessible to a wider
group, also the less technically savvy. Sure I can hack and do whatever
I want for me personally and maintain/run a fork. But the intent of my
post here on the list was to be able to make something that has a
perspective of being merged into mainline beancount/fava. Curious to
hear your thoughts about that.

Best regards,
Benjamin

[Scott]

@Benjamin -- Fava has been a great tool for me, and I appreciate the idea of wanting to make a contribution that is useful beyond your personal case.  In my mind, fava-dashboards has been a huge asset and really opened up the possibilities of what I can easily be do with fava.  I think in that spirit, the idea of generalizing and exposing fava's account view is possibly a very valuable contribution, and one I have been thinking about as well.  Specifically, I think there is a gap in that (1) fava only exposes account views based on the account tree and only exposes a few customized reports; and (2) fava-dashboards is very useful for integrating graphing and BQL; but there seems to be a gap in that the account views and reports that are native to fava aren't easily created (AFIK) through BQL queries.  I think exposing the elements of fava account/report pages so they can be easily modified ala fava-dashboards would be great

-Scott

[Simon Guest]

> It moves beancount even further away from "regular people can use it" and even further in the direction of "must know python to use it reasonably well" but I also kinda feel like that ship has largely sailed anyway.

This is an insightful comment, and one of factors motivating me in my work on limabean.

I am someone who wants Beancount but doesn't want Python. Maybe I'm unusual, at least in the present company! I also believe that everyone should be able to query their inventories without writing code.  Or at least, believing they are not writing code.

So in limabean, you show your inventory by typing this:

(show (inventory))

Yes, the user interface is in fact a Clojure REPL.  I think this is OK for regular users, and hugely empowering for power users.  Oh, it can also be used in batch mode without the REPL, like this:

limabean --eval '(show (inventory))'

Furthermore, there are increasingly many observations that notebooks are less than ideal.  See for example Joel Grus's talk, I don't like notebooks.  And also Clerk, the Clojure answer to this.

My intention with limabean is to keep it usable for the non-programmer.  But integrating Clerk would be an interesting avenue to explore for sure.

Even as one ship is sailing out of the harbour, others are sailing in. 😁