Towards a coherent Beancount developer community

[Simon Guest]

The Beancount developer landscape seems to be thriving at the moment with several recent announcements about new implementations.  This is certainly exciting, and it's great to see such creativity.

Martin has made a huge contribution to the plain text accounting community, both with the very well designed original Beancount system which we all love, and also the extensive documentation and test suite.  Thank you indeed!  These were certainly enablers for my own limabean.

And so now times are changing, and Beancount is in some ways being liberated from its Python origins.  We are seeing work in Rust, Zig, Clojure, and who knows what to come.  Exciting times indeed!  But how will we avoid fragmentation?

It is clear that in future we will have multiple implementations of Beancount-like systems.  That is not what I am concerned about.  My concerns are:

1. Preserving a common file format

2. Preserving common core behaviour

I expect and celebrate a varied approach to user interface (Beancount Query Language, Fava, or Fava-like GUI, Clojure, whatever else).  This is a fruitful area for exploration.  So too, the plugin ecosystem will surely diverge.  I agree with Moritz, the author of TurboBean (cool project!) that you wouldn't want to embed a Python interpreter just for plugins if you don't already need it.  And with limabean I am exploring the idea of not needing plugins at all.

It should be easy for users to try out different implementations, which requires (1) and (2) above, and perhaps more.

The vNext document has some interesting ideas, which explains TurboBean diverging with a new approach to inventory.  Is this the future?  I would like to know, as I would then have to follow along with limabean!

What I would really like to see is some kind of RFC process, like which is used for evolution of the Rust language and ecosystem.  I hope that Martin would like to be the BDFL for some kind of RFC-like process which unifies all these parallel developments, in terms of defining core behaviour, especially where this differs from OG Beancount (in fact, probably only where it differs).

In summary, I think we should embrace and celebrate the current divergence of implementation work in the Beancount ecosystem, but take some steps to mitigate the otherwise inevitable fragmentation.

All comments welcome!

[Moritz Drexl]

Something like this would be great to have! I am struggling a lot trying to evolve the file format and behavior along the lines of vNext while trying to keep things compatible. It would be good to have an evolving implementation-independent spec of the Beancount language that I could then just test against.

[Simon Michael]

On 2026-02-25 14:55, 'Simon Guest' via Beancount wrote:
> It should be easy for users to try out different implementations, which
> requires (1) and (2) above, and perhaps more.

Hi Simon,

A nice post. Some vaguely related things you might be interested in:

https://github.com/rustledger/pta-standards/tree/main/formats/beancount
(AI-assisted specification docs for beancount).

https://github.com/rustledger/rustledger itself has not been announced
here yet I think (AI-assisted rust rewrite of beancount - well worth
checking out). It has more technical specs at
https://github.com/rustledger/rustledger/tree/main/spec , not sure how
they differ from the above.

https://github.com/tackler-ng/pta-generator generates test data for
multiple PTA apps.

https://plaintextaccounting.org/#features and
https://plaintextaccounting.org/quickref are some older cross-app quick
references aimed at users, these may need to be updated/scaled up soon.

[Vishesh Handa]

> Martin has made a huge contribution to the plain text accounting community, both with the very well designed original Beancount system which we all love, and also the extensive documentation and test suite.  Thank you indeed!  These were certainly enablers for my own limabean.

>

> 1. Preserving a common file format
> 2. Preserving common core behaviour

I'd love some language independent tests which can be used in all beancount inspired projects. So ideally some standard input bean files, and some machine readable (maybe json) expected outputs.

Essentially some easy way to check that account balances are correct as are the inventories and precision and what not. Basically, some black box testing of all these beancount implementations, so that it's trivial to know if any project complies with the beancount spec, and maybe even a way of knowing which plugins it supports.

I have an 80% finished beancount parser in Dart, which I just wrote for fun, and it would be so helpful to know how terrible it is.

--
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/CAFhGSbuUFDWnn2vi9bZEV3%2BtKaaPTCKDdVW4jdmmS02NUVX1CA%40mail.gmail.com.

[Justus Pendleton]

I think it is a great idea to encourage experimentation and evolution of the fileformat/featureset.

My feeling is that Martin probably doesn't have the bandwidth to play any significant BDFL-type role commenting on various proposals or shepherding towards consensus. So the beancount family is probably better served with something a bit more free-form. I could see value in a centralised repository where alt-beancounts could post "hey, here's what I'm trying out", a bit like we've seen with the various flavours of markdown over the years which also don't have a BDFL but have evolved in a bit more chaotic fashion.

I think the biggest value-add at the moment would simply be some kind of unique number for each change from vanilla-beancount so people could talk about "change #12 in limabean is easier to use but less powerful than the similar change #26 in prolog-bean" and provide a focus for discussions like RFCs do. I can't imagine trying to enforce too much structure on either the document or the process would be very useful, simply because I imagine most people writing alt-beancounts aren't terribly invested in writing long documents in prescribed formats for what is still largely a personal project.

But if you have more lightweight examples from smaller projects (i.e. not rust or python which understandably have rigorous processes) it might help generate more ideas.

[Simon Guest]

Dart? Awesome!

I extracted all the OG Beancount parser tests from their original Python into language-independent files here:

https://github.com/tesujimath/beancount-parser-lima/tree/main/test-cases

Input files are standalone Beancount. Expected output as text protobuf.

All credit to Martin for the original tests!

I'm afraid my booking tests are embedded in Rust, sorry. (Also adapted from Martin's originals.)

https://github.com/tesujimath/limabean/blob/main/rust%2Flimabean-booking%2Fsrc%2Ftests%2Fbooking.rs

To view this discussion visit https://groups.google.com/d/msgid/beancount/CAKb-1of4jW46%3DjU6ApRGCD_xaHKmvFQxo29eUBHir1o5qLdkMQ%40mail.gmail.com.

[Martin Blais]

So long a thread.

I appreciate the flowers but let's not forget the original idea is a John Wiegley creation, I merely copied and then iterated and recreated a few times. Simon Michael also accumulated a following with his Haskell work. Credit where credit is due.

Re. BDFL indeed I don't have time. I'm giving all my cycles to someone else at the moment. (Thankfully doing lots of agentic stuff so it's not like I have FOMO.)

I think the idea of having unified tests is a great one but it's unlikely to happen, people enjoy the 0 to 1 feeling mostly and this won't change with agents. Maybe you can extract all the tests from my source code and find a way to them across equivalent systems (see how I assert some things in the beancount syntax itself, you don't necessarily need code, you can create a syntax). 

The main challenge to new implementors is going to be completeness. 

With the AIs zero-to-0.8 is almost instant; your enemy will be 0.8 to 1.0. 

Lots of little details to care for.

--

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/3a441c4c-5e54-4ef0-bc6d-39f7bb683923n%40googlegroups.com.

[Simon Guest]

So, towards caring for those little details in a collaborative way, how do you feel about creating a new GitHub repo, say, beancount-vnext-rfc in the beancount organization?  The intention being that developers wishing to gain some clarity on what to implement can create an issue, and interested parties can comment.  That way we will collect the discussion in a central place which is searchable and contains the full history of comments on each topic.  GitHub issues are quite good for this, as anyone can subscribe to an issue or to the whole repo.

We have seen two instances of this being required already, regarding the new approach to inventory being taken by TurboBean, and the false-start on plugins I was investigating.  It is clear that this mailing list is not going to suffice, and trying to discuss all that here is only going to annoy people who aren't interested in alternative implementations (which I concede may be most people right now).

If you created the repo and gave me write access, I could set up an RFC template to try to get things going in the right direction.

To view this discussion visit https://groups.google.com/d/msgid/beancount/CAK21%2BhPGzU%2BFjuKh_oxXsQ7eQMcigTUVygPv%3DQPQ8Do%3DqO-iEg%40mail.gmail.com.

[Martin Blais]

On Tue, Mar 3, 2026 at 10:58 PM 'Simon Guest' via Beancount <bean...@googlegroups.com> wrote:

So, towards caring for those little details in a collaborative way, how do you feel about creating a new GitHub repo, say, beancount-vnext-rfc in the beancount organization?  The intention being that developers wishing to gain some clarity on what to implement can create an issue, and interested parties can comment.  That way we will collect the discussion in a central place which is searchable and contains the full history of comments on each topic.  GitHub issues are quite good for this, as anyone can subscribe to an issue or to the whole repo.

I don't mind creating beancount-rfc but I think it won't work.

We have seen two instances of this being required already, regarding the new approach to inventory being taken by TurboBean, and the false-start on plugins I was investigating.  It is clear that this mailing list is not going to suffice, and trying to discuss all that here is only going to annoy people who aren't interested in alternative implementations (which I concede may be most people right now).

If you created the repo and gave me write access, I could set up an RFC template to try to get things going in the right direction.

Sure, I can do this over the weekend

To view this discussion visit https://groups.google.com/d/msgid/beancount/CAFhGSbt4fY0W6dX-Zd9W2%2B3PdGnSXPQZsBzGUsiQwspGQLnPPw%40mail.gmail.com.

[Simon Guest]

Well, if you think it won't work then perhaps it's not a good idea! 

Are you thinking there is insufficient interest in the community for refining such ideas collaboratively? If that really is the case then I fear we are doomed to suffer from fragmentation, as different people go off with their own ideas in different directions, and we lose a coherent vision for what it means to be a Beancount implementation.

Or did you see a different problem?

To view this discussion visit https://groups.google.com/d/msgid/beancount/CAK21%2BhN33-5u0hb8d7%3DVOo-LXczMHjV59GzDb03S6gajze2CWw%40mail.gmail.com.

[Simon Michael]

I also think it won't work, if the idea is for everyone to work together
in that repo. There just isn't enough incentive to get people
consistently allocating time to that.

If there's one rather active person absorbing and curating and editing
ideas from the ecosystem, that might work. Or possible 2-3 active
people. What would help sustain the motivation for this ?

> enablers for my own limabean <https://github.com/
> tesujimath/limabean>.

>
> And so now times are changing, and Beancount is in
> some ways being liberated from its Python origins.
> We are seeing work in Rust, Zig, Clojure, and who
> knows what to come.  Exciting times indeed!  But how
> will we avoid fragmentation?
>
> It is clear that in future we will have multiple
> implementations of Beancount-like systems.  That is
> not what I am concerned about.  My concerns are:
>
> 1. Preserving a common file format
>
> 2. Preserving common core behaviour
>
> I expect and celebrate a varied approach to user
> interface (Beancount Query Language, Fava, or Fava-
> like GUI, Clojure, whatever else).  This is a
> fruitful area for exploration.  So too, the plugin
> ecosystem will surely diverge.  I agree with Moritz,

> the author of TurboBean <https://github.com/
> themoritz/turbobean> (cool project!) that you

> wouldn't want to embed a Python interpreter just for
> plugins if you don't already need it.  And with
> limabean I am exploring the idea of not needing
> plugins at all.
>
> It should be easy for users to try out different
> implementations, which requires (1) and (2) above,
> and perhaps more.
>

> The vNext document <https://beancount.github.io/
> docs/beancount_v3.html> has some interesting ideas,

> which explains TurboBean diverging with a new
> approach to inventory.  Is this the future?  I would
> like to know, as I would then have to follow along
> with limabean!
>
> What I would really like to see is some kind of RFC
> process, like which is used for evolution of the
> Rust language and ecosystem.  I hope that Martin
> would like to be the BDFL for some kind of RFC-like
> process which unifies all these parallel

> developments, in terms of defining core behaviour, /
> especially where this differs from OG Beancount/ (in

> fact, probably only where it differs).
>
> In summary, I think we should embrace and celebrate
> the current divergence of implementation work in the
> Beancount ecosystem, but take some steps to mitigate
> the otherwise inevitable fragmentation.
>
> All comments welcome!
>
> --
> 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

> <mailto:beancount+...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/
> d/msgid/beancount/3a441c4c-5e54-4ef0-

> bc6d-39f7bb683923n%40googlegroups.com <https://
> groups.google.com/d/msgid/beancount/3a441c4c-5e54-4ef0-
> bc6d-39f7bb683923n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

>
> --
> 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

> <mailto:beancount+...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/
> msgid/beancount/

> CAK21%2BhPGzU%2BFjuKh_oxXsQ7eQMcigTUVygPv%3DQPQ8Do%3DqO-
> iEg%40mail.gmail.com <https://groups.google.com/d/msgid/
> beancount/
> CAK21%2BhPGzU%2BFjuKh_oxXsQ7eQMcigTUVygPv%3DQPQ8Do%3DqO-
> iEg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> 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

> <mailto:beancount+...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> beancount/CAFhGSbt4fY0W6dX-
> Zd9W2%2B3PdGnSXPQZsBzGUsiQwspGQLnPPw%40mail.gmail.com <https://
> groups.google.com/d/msgid/beancount/CAFhGSbt4fY0W6dX-
> Zd9W2%2B3PdGnSXPQZsBzGUsiQwspGQLnPPw%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

>
> --
> 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

> <mailto:beancount+...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> beancount/CAK21%2BhN33-5u0hb8d7%3DVOo-
> LXczMHjV59GzDb03S6gajze2CWw%40mail.gmail.com <https://
> groups.google.com/d/msgid/beancount/CAK21%2BhN33-5u0hb8d7%3DVOo-
> LXczMHjV59GzDb03S6gajze2CWw%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

>
> --
> 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

> <mailto:beancount+...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/

> beancount/CAFhGSbveq8AWX-
> SA%2BZCPU1Eg27YNoRaQb2Tknj_%3D2BRtaUeZxQ%40mail.gmail.com <https://
> groups.google.com/d/msgid/beancount/CAFhGSbveq8AWX-
> SA%2BZCPU1Eg27YNoRaQb2Tknj_%3D2BRtaUeZxQ%40mail.gmail.com?
> utm_medium=email&utm_source=footer>.

[Simon Michael]

PS related, where would you draw the line to limit the scope of work ?
I think you said "Beancount-like systems", rather than "plain text
accounting systems". I can understand picking either one (lots of work
either way).

[Simon Michael]

Oh in fact, "Beancount developer community" is right there in the
subject. I am usually thinking about the larger ecosystem, so my
comments might not be so relevant in this thread.

Beancount-like systems are multiplying and influencing the PTA ecosystem
strongly, so it's all interconnected...

[Simon Guest]

OK, let's not do that then.  Sadly I do think you're both right.

It seems like the best we can do is for all the next-generation Beancount developers to pay attention here and discuss their ideas on this list.  Hopefully this won't be too annoying for the majority of people who may not be that interested.  But I suspect the volume will be quite low.  And at least anything contentious will get the opportunity of feedback from a wider audience.

cheers,

Simon

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/0ce244dd-6b4f-454c-aa58-d6dd1bc92448%40joyful.com.

[Simon Guest]

Yes indeed, there have been a whole host of Beancount-like systems appearing recently.  Here's to a good collaboration over the nuances of how they should behave! 🍻

[Martin Blais]

On Wed, Mar 4, 2026 at 7:17 PM 'Simon Guest' via Beancount <bean...@googlegroups.com> wrote:

Well, if you think it won't work then perhaps it's not a good idea! 

Are you thinking there is insufficient interest in the community for refining such ideas collaboratively? If that really is the case then I fear we are doomed to suffer from fragmentation, as different people go off with their own ideas in different directions, and we lose a coherent vision for what it means to be a Beancount implementation.

Or did you see a different problem?

I just think ideas that work always come bottom up. It's so rare that someone says "let's form a group to achieve X" and then "X" gets achieved. The working dynamic in open source is one or a few individuals axed to get something they really really personally want and then take enough pride in it to make it available to others. That's why nearly all the open source project have 1 or few principal creators.

Look I don't want to discourage you, I'm just saying, if you really want something done, drive it yourself without trying too hard to get consensus from other people. To recycle the trope: just do it. Do things the way you dream of, and if it's great you'll then have some takers to discuss with.  I've shared all my ideas on what I think needs to be done on Beancount in these documents, feel free to recycle or ignore them or take them to a brand new place your own.

To view this discussion visit https://groups.google.com/d/msgid/beancount/CAFhGSbveq8AWX-SA%2BZCPU1Eg27YNoRaQb2Tknj_%3D2BRtaUeZxQ%40mail.gmail.com.

[Simon Guest]

Thanks Martin, that's really empowering! ❤️

To view this discussion visit https://groups.google.com/d/msgid/beancount/CAK21%2BhPGBL-b1J0OE9_oCOk3DWGXH_A0BLK_gORanfoV_fEe3A%40mail.gmail.com.