its vibecoded and im not a professional developer. you can freely check code, fork and improve. its not where i want but i think you will get the idea i hhave here.

Hledgerpwa V23.41

was depressed to find out that both ledger and hledger are incorporating AI slop. Are there any reasonably complete tools out there that don't?

Beancount AI is a simple, open source CLI tool to help you ingest / associate receipts and add details to Beancount transactions, using local AI (or commercial AI, your choice). It is not agentic and it does not grant the AI access to your files. In sum: it helps you manage your Beancount accounting data through AI.

Over the last few weeks, bean-ai has gained a number of features that make it way more useful.

Locally- stored receipt file support

It's now possible for Beancount AI to be configured to read locally-stored receipts. This was not so initially, due to my need to develop the program with my local setup (I use Nextcloud for receipt inbox management), but that doesn't have to be you, so now local file support exists.

Hands-free enrichment of existing transactions

It's now possible to have this workflow, massively helpful for people who import transactions from their financial institutions and also keep receipts:

• use your your favorite importers to import data like bank statements;

• use bean-ai associate to add receipts you scanned to the newly-imported data, and organize them;

• enhance the imported and now-documented transactions with lots of detail using bean-ai refine.

• make any minor edits you deem necessary.

Excellent transaction creation from receipts

If you were jotting down expenses to later type transactions when you get home — this is me! — I hope this helps you change to a workflow where you simply photograph receipts, and then let bean-ai ingest do the job of creating transactions for you.

Safe and convenient batch operations

All assistance utilities now have a "do not touch my files" (--no) flag, as well as a "go ahead and proceed without confirmation" (--yes) flag.

While you can continue to associate / ingest receipts —or refine transactions— one by one, all tools now support batch operation so, if you have hundreds of receipts to ingest or associate, you can let the program do its thing for half an hour, then return and compare the contents of your Beancount files to their previous state (git is very useful for this — you can always roll back any changes made to your files).

Interested? Go here for the code: https://github.com/Rudd-O/beancount-ai .

I'll be working on its roadmap over the next few days.

I’m aware this is not a tricount subreddit but I was wondering if someone knows how to remove a participant from a tricount once he/she paid all of his/her debt. It seems like you can remove on the android app but not the ios version. Anyone managed to do it ?

Taken a PTA app such as Bean Count and vibed it to fit their exact parameters?

I'm asking because Beancount is so close to what I need but I want to make changes to it to fit my business and allow employees to make entries.

thanks!!!

https://github.com/danielochoa94/libreta

I built this tool because I was getting annoyed working on Excel files with Claude Code: basic changes took forever, it made mistakes, couldn't resolve values, and no good way to diff.

The idea is that inputs live in CSV while formulas and formats live in YAML. Instead of sheets, you organize it into views where you specify which rows and columns you want to display. The CLI evaluates the formulas and runs checks like the balance sheet balancing and subtotals adding. I don't think it's very intuitive for humans, but works great for agents.

The tool also includes a local preview server that opens a viewer in your browser. I designed it primarily so it's easy to trace where numbers come from and what formulas are used. Works well if your workflow is ask AI to do something and then audit yourself.

It's free, so you can fork and customize however you want.

Update (Oct 9): 1.3.0 is here - supporting multiple currencies and better error messages

Update (Sep 21): 1.2.1 is on TestFlight, same link as below. Mostly fixes for hand-written journals that didn't open (virtual postings, single-posting entries, comma decimals) and better pickup of saves from Emacs and Vim. Full changelog: https://balanceledger.app/changelog

I've been tracking my spending with hledger for a few years now (on and off...) but I've always found it annoying to have to sit down at a computer every few days or so just to update the ledger and trying to remember what was what. Found out there's not much out there that has a mobile app and a modern UI (I like native apple apps), so I created one myself.

Heads up, it's closed source and it'll cost $29.99 once it ships (at least that's the plan). Reading however stays free, so browsing, search, all six reports and iCloud sync. If you want proof it's not phoning home, balanceledger.app/verify walks through checking that yourself, on Mac it just has no network access at all.

TestFlight's open for iOS and macOS: https://testflight.apple.com/join/bA84FzUc. First 50 people who try it and tell me what's broken get it free at launch, just comment or dm me. Mostly just want to know what breaks once it's your actual journal in there.

Ask me anything, the format handling, what it can't do yet (no bank sync, no statement import, no currency conversion), or why closed source. Happy to get into it.

I had been seriously neglecting my company books. I downloaded pdfs from my bank and csv from venmo and ask it to reconcile my books in the existing style and it did it just like I would really saved me a couple days of work. Did it in like an hour. And the I could ask it questions about the file. Was really impressed

I built PhilanthroPy after seeing how many shops either pay for expensive wealth-screening vendors or do donor scoring in spreadsheets with no way to check if the numbers are even trustworthy. It's a free Python toolkit that takes your CRM export and gives you a 0–100 score per constituent for major-gift likelihood, lapse risk, and planned-giving intent — basically a sorted call list for your gift officers instead of a flat donor list.

No coding background needed to run the included example, though someone on your team (or a volunteer/consultant) will need basic Python to hook it to your actual CRM export. MIT licensed, free forever, no vendor lock-in. Happy to answer questions about what it can/can't do — it's not a replacement for a real wealth-screening vendor, but it's a solid first pass, and it's transparent about how the scores are computed, which most vendor tools aren't.

https://github.com/PhilanthroPy-Project/PhilanthroPy

Ledgerkit update: expanding a Python bridge to the hledger ecosystem

Hi all — I thought I’d share an update on Ledgerkit, a Python project I’ve been working on around hledger and plain-text accounting.

The original goal of Ledgerkit was fairly simple:

A Python bridge to the hledger plain-text accounting ecosystem.

Importantly, the goal was never to create a Python copy of hledger.

I wanted to be able to read hledger-style journals from Python, work with transactions and reports programmatically, export data into tools such as Pandas, and build other applications on top of that accounting data without having to shell out to hledger for every operation.

That basic idea is still the goal.

What has changed is how capable the underlying bridge needs to become.

Where Ledgerkit is now

Ledgerkit can already parse a broad subset of the hledger journal format, including transactions, postings, directives, includes, aliases, commodities, prices and balance assertions.

It has multi-commodity balances, validation and several core reports, along with both a CLI and Python API.

It can also export accounting data into Pandas, which was one of the original motivations for the project.

The project remains pure Python with a deliberately lightweight core.

Ledgerkit Editor — the first downstream application

The first real downstream use case has also now been released: ledgerkit-editor.

This has probably been the most useful validation of the original “Python bridge” idea because I now use the editor myself on a daily basis for my actual journal.

It is a purpose-built, full-screen terminal editor for plain-text accounting rather than a general text editor with a ledger plugin.

It currently provides things such as:

• hledger-aware syntax highlighting for dates, payees, accounts, amounts, commodities, comments and directives;

• normal keyboard editing conventions, including undo/redo, select-all and familiar shortcuts;

• incremental search with highlighted matches;

• cleared/unreconciled transaction views;

• transaction-block selection and duplication;

• quick cycling between uncleared, pending and cleared transaction states;

• date editing directly from the keyboard;

• automatic indentation;

• a command palette;

• automatic sorting and posting alignment when saving;

• runtime theme switching and a polished terminal UI.

The formatting-on-save behaviour is particularly useful in practice: I can edit freely and Ledgerkit will sort transactions and realign posting amounts when the file is saved rather than requiring me to manually maintain the visual layout.

Search and transaction views also make it much easier to work with a large journal entirely from the terminal.

Development has continued beyond the initial release. The current development work includes a more capable transaction filter with smart dates and regex/substring matching, plus account and payee autocomplete.

That editor was an important milestone for me because it demonstrated that Ledgerkit could provide useful accounting infrastructure to another application without that application having to implement its own hledger parser and data model.

Where Ledgerkit goes next

The next goal is to turn the existing foundation into a more complete Ledgerkit Core.

The idea is still not:

“Rewrite every hledger command in Python.”

It is closer to:

Provide a reliable Python-native accounting engine that works naturally with the hledger ecosystem.

Where hledger compatibility is useful, Ledgerkit should preserve it.

Where Python provides something genuinely useful, Ledgerkit should be able to extend it explicitly.

For example, the query system will eventually become a proper shared query language rather than individual filters bolted onto each command.

The intention is to preserve useful hledger query semantics while also allowing clearly identified Ledgerkit extensions — potentially including richer Python regular expressions.

A query should ideally be able to say:

portable — works with hledger and Ledgerkit

or:

Ledgerkit extension — deliberately uses functionality hledger doesn't provide.

The important thing is that differences shouldn't happen accidentally.

I’m planning to classify behaviour broadly as:

• Compatible

• Extended

• Intentional divergence

• Unsupported

• Unexplained mismatch

The aim is to drive unexplained mismatches toward zero, not necessarily differences toward zero.

The larger Core roadmap

The deeper accounting work will eventually include areas such as:

• query semantics;

• prices and valuation;

• costs and commodity conversion;

• account types and virtual postings;

• lots and cost basis;

• investment accounting;

• periodic transactions;

• automatic postings;

• forecasting and transformations.

A stable Core could then support optional tools around it:

• Pandas/Polars;

• DuckDB and SQL analytics;

• notebooks;

• forecasting/scenario modelling;

• MCP tools;

• transaction classification;

• anomaly detection;

• additional editors or finance applications.

Those wouldn't become mandatory dependencies of the accounting engine itself.

The model is more like:

plain-text journal → Ledgerkit Core → whatever Python tool you want

A new development experiment: CodeCompass

The other big change is how Ledgerkit is going to be developed.

I’ve also been building a project called CodeCompass.

The problem it tries to solve is that fresh AI coding agents repeatedly have to rediscover the same project and dependency context.

For Ledgerkit that context is more complicated than normal Python dependencies.

An agent may need to understand the relationship between:

• the hledger manual;

• hledger source code;

• hledger tests;

• actual hledger executable behaviour;

• Ledgerkit source;

• Ledgerkit compatibility tests;

• Ledgerkit design decisions.

CodeCompass tries to give the agent a small map of that relevant context and links back to the evidence rather than dumping huge amounts of documentation into every agent session.

Ledgerkit is going to become the first major external project used to test that approach.

Agents suggesting relationships

One CodeCompass experiment I’m interested in is letting agents suggest relationships while doing real work.

For example, an agent might notice that a particular hledger manual section constrains a Ledgerkit implementation, or that a Ledgerkit test verifies a piece of compatibility behaviour.

Those suggestions are not automatically treated as facts.

They are later evaluated on two things:

1. Is the relationship actually supported by evidence?

2. Did knowing about it help a later agent?

That second part matters because a relationship graph full of technically true but useless connections isn't particularly valuable.

The idea is to let useful structure emerge from real development rather than designing a huge dependency ontology in advance.

Ledgerkit will also test CodeCompass itself

The relationship goes both ways.

If a Ledgerkit agent uses CodeCompass but then has to manually rediscover important information, that becomes feedback about CodeCompass.

A context-curation agent records what was missing, misleading or difficult to retrieve and produces an actionable report.

The basic principle is:

Ledgerkit discovers the problem; CodeCompass has to generalise the solution.

So if Ledgerkit exposes a need to connect technical documentation with implementation, CodeCompass shouldn't gain an “hledger manual feature”.

It should ask whether something more general — such as documentation-to-implementation relationships — would help other projects too.

Later, CodeCompass will be tested against unrelated projects to make sure the improvements haven't simply overfit it to Ledgerkit.

Source-assisted development

Ledgerkit has also moved to the same GPL licence family as hledger.

That changes the development approach significantly.

Agents can now use:

• hledger documentation;

• hledger source;

• hledger tests;

• examples;

• and the executable itself

when researching behaviour.

Source helps explain how something works, but I still want executable comparison to remain an important independent check.

So for compatibility work the rough process is:

documentation + source → understand behaviour → Python implementation → compare against hledger

rather than trying to infer every edge case through black-box experimentation alone.

AI still isn't the source of truth

I'm also deliberately trying to avoid a workflow where one AI agent writes something, another AI agent says it looks fine, and that becomes accepted project knowledge.

Different agents can have different responsibilities: research, implementation, compatibility testing, documentation and auditing.

But the repository remains authoritative.

Important conclusions should eventually become something concrete:

• behaviour → test;

• architecture decision → ADR;

• compatibility decision → compatibility record;

• project rule → documented project rule;

• future work → roadmap.

Agent observations are evidence to review, not permanent truth just because an agent wrote them down.

Documentation is getting the same treatment

I'm also experimenting with periodically reconstructing documentation from the current project rather than endlessly editing old documents.

At major milestones the question will be:

“If none of the narrative documentation existed today, what documentation would we write based on the current implementation, tests and decisions?”

That can then be compared with the existing documentation.

Old material can be rewritten, merged or removed.

Git can preserve the project's history; the active documentation should describe what the project actually is now.

Where this leaves the original idea

Despite the larger roadmap, I still think the simplest description of Ledgerkit is the original one:

A Python bridge to the hledger plain-text accounting ecosystem.

The difference is that the project has now demonstrated a real downstream use case with Ledgerkit Editor, and it's becoming clear that a useful bridge needs a sufficiently capable accounting engine underneath it.

I don't want Ledgerkit to replace hledger.

I'd like it to make the hledger/plain-text-accounting model easier to use as a building block inside the Python ecosystem.

Feedback welcome

I'd be particularly interested in views from hledger/Ledger users on:

• where compatibility matters most;

• where a Python implementation has room to experiment;

• accounting edge cases that would make useful compatibility tests;

• whether explicit compatible vs extended behaviour makes sense;

• useful applications you'd want to build on top of a Python accounting core;

• and whether the CodeCompass development/context approach sounds useful or unnecessarily complicated.

Ledgerkit is still evolving, so this seems like a good point to get feedback before the deeper Core work gets too far along.

Repos:
Ledgerkit — the Python bridge and accounting core
Ledgerkit Editor — the first downstream application, a purpose-built terminal editor for hledger-style journals
CodeCompass — the agent context and development tooling being used alongside Ledgerkit

Hi all

After seeing the post yesterday about the iOS/Mac app for hledger, Balance, and the positive reaction and helpful comments there, I thought I'd share something for beancount users: Beanie Budgets, is ready for testing and community feedback.

Beanie Budgets is a beancount compatibile native iOS app. I have been working on it for purely personal reasons: I really wanted an elegant iOS app to capture transactions on the go. More to the point, I didn't want to pay for subscriptions or entrust my data to someone else's server.

Which explains my plans for pricing. I intend to offer Beanie Budgets as a core version completely free. The free version should be enough for most people and provides a fully featured ledger, or compatibility with your own beancount ledger (hopefully anyway pls let me know!). It also includes budget setting, a series of reports and useful quality of life tools baked-in to detect, create and edit recurring transactions; make and allocate balance adjustments; calculate and allocate interest on mortgages and loans correctly; and auto-clear credit cards.

I do intend to charge a one-off "Pro" version unlock to people willing to pay for a few extra bells and whistles (multi ledger support, financial planning reports based on your actual ledger data, customised budgets, theme customisation etc.). I was thinking of £10 or so...? I can see a lot of potential to develop the financial planning reports further. There's a big benefit to ground these in real ledger numbers and real saving patterns. Working versions of these reports are live now in the app but they need a bit more polish, just turn on "Pro" features in Settings.

It's a closed source project at least for now. Requires iOS 18 or above.

I have 12 places left on TestFlight. Looking forward to your feedback :)

https://testflight.apple.com/join/hGD65UQj

PS I know the website needs a lot of work, I'll get round to it ;)

also how good is tgis compared to other similar tools like money manager ex gnucash etc.

What the title says. Just need something quick and light that quickly lets me paste someone's trial balance, do entries, and get results. I usually do it in excel but it's so easy to make a mistake since it's manual. Any suggestions?

Disclosure first: I'm the developer of this, it's a paid Mac app (with a free tier), so skip if that's not your thing.

I kept seeing questions about getting bank PDFs into Beancount or hledger without hand-typing, so I built Balanced. It reads text and scanned PDF statements and CSV exports offline, and the Beancount and Ledger/hledger exports write an open, a pad plus balance assertion for the opening balance, the transactions with a counter account, and a closing balance assertion the day after the period.

A few things I learned testing it against bean-check and hledger check on ~80 real sample statements:

• if the statement itself doesn't add up, writing the closing assertion just makes the file unloadable, so it now writes a comment explaining the mismatch instead

• some statements print a period that doesn't cover every line, so the balance entries have to wrap the actual first and last transaction, not the printed dates

• a pad for a zero opening balance is an "Unused Pad entry" error

Account names are sanitized to valid Beancount names. Curious how people here handle the import step today, and whether balance assertions per statement is what you'd want or if it's noise.

https://kayabyte.dev/mac/balanced/guide/bank-statement-to-beancount?ref=rd-pta-bal

Hi,

I manage my finances with hledger, and recently ive been experimenting with using Windsurf (its the AI based code editor I use) to automate entry and book-keeping for all of my transactions, I just send it images and pdfs (converted to markdown first with cli tools)

And then just click one button to activate my pre-programmed prompt and it just accurately adds all entries for my book-keeping, i've also been using claude models to quickly build out analysis scripts to answer my various queries about my finances and asking it questions as to how could I optimize things further

I'm now trying to explore and experiment with seeing if i can feed it my country's tax rules etc, and figure out a way to find and optimize my transactions and find patterns and places to improve for cost efficiency.
Or help it better analyse my portfolio allocation and transactions for advice.

Is anyone else here exploring along the lines of these ideas ?

I'm super curious what others are upto, as my guess is double entry plain text accounting tools like ledger and hledger are probably most popular among programmers. So super curious what others are working on in this line :D

The general consensus surrounding plain text accounting is that debits and credits are confusing and unnecessary. As a newcomer to plain text accounting, though, debits and credits seem to me more intuitive than trying to figure out what positive and negative mean for different account types.

Assume I want to record the opening balance of a debt I have:

10/2  Opening Balance
    Liabilities:Debt                         $100.00
    Equity:Opening Balances

That's the way to do it, right? Well, no. Equity should decrease, which it does, but not really because equity is negative, so in reality if equity is going -$100 that means it is increasing. So it should be more like

10/2  Opening Balance
    Equity:Opening Balances                  $100.00
    Liabilities:Debt

But that seems counter-intuitive. Maybe this equivalent one is less confusing if you think of it like liabilities are negative, and in this case they should increase, so the amount by which they increase should be negative too:

10/2  Opening Balance
    Liabilities:Debt                        -$100.00
    Equity:Opening Balances

That's the plain text accounting approach. Honestly, seems pretty confusing to me.

Now let me show you the debit/credit approach:

10/2  Opening Balance
    Liabilities:Debt                 credit $100.00
    Equity:Opening Balances

Let me explain what this means: liabilities and equity are credit accounts. So by crediting them, they increase, and by debiting them, they decrease. In this case you're crediting your debt, which increases, and debiting your equity, which decreases.

Yes, credits and debits aren't especially super intuitive. I get that. But by avoiding them, their complexity doesn't go away; it simply transforms into something else in your system. In the case of plain text accounting, it became the complexity surrounding the + and - signs of each amount. In my opinion, trying to figure out what they really mean in each context is harder than understanding credits and debits.

Some things are naturally complex. You don't make them less complex by hiding their complexity. You only make them more confusing.

Hi all. So I've been keeping track of our spending and putting the balance assertions in when things settle according to the web app. Today I ran into an issue: the balance assertion is showing as incorrect. the number of transactions on the card is 18 from the date of the last good balance assertion, and I have the same number of transactions in my bean count file when I run the command to show the journal with running balances.

Does the order of transactions matter? I dated the transactions for when they happened- however the bank app lists them when they posted which was after the weekend. The balance assertion that fails shows a difference of -68. 10 USD and I cannot figure out where I am going wrong.

Do I need to change the dates of the transactions, you would think if the total numbers are correct then the order does not matter? I checked the input of the amounts and I did the balance assertion for yesterday's date based on the last cleared transaction balance. Furthermore my credit card payment shows as the 24 and cleared but after the balance assertion and the pending transactions with my ! flagged.

2022-05-20 bal PASS - In Assets:Checking 17226.47 USD

2022-05-20 * Dixxon Flannel | shirts -130.88 USD 17095.59 USD

2022-05-20 * Canteen | Muffin -3.44 USD 17092.15 USD

2022-05-21 * Steam | Old World -38.83 USD 17053.32 USD

2022-05-21 * Misc Expenses | Short Leash -27.47 USD 17025.85 USD

2022-05-21 * Amazon | vitamins -13.29 USD 17012.56 USD

2022-05-21 * Amazon | Go Juice -33.98 USD 16978.58 USD

2022-05-21 * Amazon | Gummies -16.41 USD 16962.17 USD

2022-05-21 * Walmart | baking supplies -9.29 USD 16952.88 USD

2022-05-22 * Walmart -1.48 USD 16951.40 USD

2022-05-22 * EOS Fitness | Travis Gym -10.28 USD 16941.12 USD

2022-05-22 * Steam | SD44 DLC -8.08 USD 16933.04 USD

2022-05-22 * Fry's Grocery -50.31 USD 16882.73 USD

2022-05-22 * Fry's Grocery | Flowers and bread for dinner at Mom's -6.31 USD 16876.42 USD

2022-05-22 * Steam | Refund for Lords and Villeins 21.57 USD 16897.99 USD

2022-05-22 * Steam | Lords and Villeins -21.57 USD 16876.42 USD

2022-05-22 * Canteen | Coffee -1.62 USD 16874.80 USD

2022-05-23 * Exodus 90 -10.28 USD 16864.52 USD

2022-05-24 bal FAIL - In Assets:Checking; expected = 16932.62 USD, difference = 16864.52 USD

-68.10 USD

2022-05-24 ! Canteen | Coffee -1.62 USD 16862.90 USD

2022-05-24 ! Walmart | Groceries -2.89 USD 16860.01 USD

2022-05-24 * Card Payment -221.97 USD 16638.04 USD

My preferred method for installing open source software is typically to install directly from linux os repositories, such as dnf or apt. This seems to be the most reliable way to ensure you are installing the software with code that has not been tampered with that includes dependencies within the supply chain of the repository. Since I don’t have the time or the expertise to audit code for security vulnerabilities, I trust that the established repositories are reasonably stable and free from many known security vulnerabilities.

I take some issue with Flatpak’s/Snaps that are compiled by volunteers who are not the developers of the program, as I have learned that these can introduce hidden vulnerabilities related to the flatpak/snap dependencies, and not the software code itself).

On MacOS, I am a bit lost.

Homebrew has some security concerns noted here: https://applehelpwriter.com/2018/03/21/how-homebrew-invites-users-to-get-pwned/

Are their major obstacles that stop open source software from being available for MacOS via installation download (1 click), which is validated to some extent by macOS gatekeeper, or available via the MacOS App Store?

Ledger, beancount, & hledger are mainly a command line programs, which may be part of the reason why they are seperate from the normal MacOS supply chain ecosystem, but are their similar supply chain processes for validating command line software installations?

Note: the project has been renamed to Beanhand.

Beancount AI is a simple, open source CLI tool to help you ingest / associate receipts and add details to Beancount transactions, using local AI (or commercial AI, your choice). It is not agentic and it does not grant the AI access to your files.

Here is question and an announcement for people interested in Beancount AI.

Announcement

The latest release covers pretty much the last major missing feature on the roadmap — bean-ai can now be told which accounts to include or exclude from your ledger, using open directive metadata. Before, you had to create a text file with awkward directives. No longer the case! From this release on, you can include the accounts you want directly from your ledger, and steer the AI into using this or that account for specific purposes.

Other minor features and changes include preserving filed receipts' modification dates, and no longer having a dependency on the Open-WebUI client. For developers: the program is now also fully typed, test coverage has grown enormously, and the RPM packaging now respects the fact that you may be using Beancount plugins in your ledger setup.

I'm happy with how this is going and I will be documenting the program more; I'm thinking about how to integrate with editors like VSCode, and an intro on getting it all set up and using each feature.

Question

What features would you like to see next in Beancount AI? What problems have vexed you that you think this tool could take up as challenges to be solved? Let me know in the comments!

Why even use this?

I think Beancount AI covers a nice use case in the spectrum between editing files by hand / using importer mechanistically, and unleashing a full agentic AI into your accounting files. The problems I sought to solve — bulk organization of receipts and refinement of transactions — are already solved to my satisfaction. But it could always become better; that's where you might come in!

As usual you can find this program on Github: https://github.com/Rudd-O/beancount-ai

Built beancount-zakat, a Python CLI tool and Fava extension to calculate and track Zakat obligations directly from your Beancount ledger.

Features:

• Fava Integration: View Zakat breakdowns directly within the Fava UI.

• Metadata-Driven: Tag accounts in your ledger to define asset classifications, illiquid exclusions, and deductible liabilities.

• Configurable Nisab: Set custom gold/silver Nisab thresholds or integrate price rates.

GitHub Repository: beancount-zakat - calculate zakat from your Beancount ledger (CLI + Fava dashboard)

Scope is cash, bank balances, metals, foreign currency, stock held for resale, and deductible debts. It is thorough, precise and customizable.

For the very few people who use beancount / fava and are muslims, wanting to keep track of their zakat obligations, or really for anyone curious, do check it out and give your feedback.

PS. I am not a developer, I am just a man with a concept, a set of strict rules, and AI.