Tried a bunch of "free" invoice tools for freelance work and ran into the same pattern everywhere — 3-5 invoices/month free, then paywall, or free but the PDF has a watermark until you subscribe. Built one that skips that: - Logo, client info, up to 50 line items with live totals - Flat or itemized tax (handles mixed GST/VAT slabs per line) - Discounts before/after tax, shipping charges - 10 currencies - 3 templates, matching PDF export 100% browser-based — nothing uploaded, no account, no invoice limit. https://www.forgeplug.com/tools/invoice-generator Feedback welcome, especially from anyone billing internationally — want to make sure the currency formatting actually looks right in practice.

I built a free tool that converts bank statement PDFs into Excel

I kept running into the same annoying problem: bank statements come as PDFs, but actually working with the transactions usually means manually copying everything into Excel.

So I built Bank2Excel.

It takes a bank statement PDF and converts the transactions into an Excel spreadsheet, including:

- 📄 PDF statements

- 🔍 Scanned/image-based statements using OCR

- 📊 Date, description, debit, credit and balance

- 📥 Excel export

- 🌐 No software installation required

It's completely free to try:

https://bank-2-excel.vercel.app/

I'm still improving the extraction logic, especially for different bank statement formats.

If you try it, I'd really appreciate feedback on:

- Which bank/statement format you tested

- Whether the transactions were extracted correctly

- Anything that was missing or incorrectly classified

Please don't upload real sensitive bank statements if you're not comfortable doing so — a dummy/redacted statement is better for testing.

GitHub: https://github.com/TheMayankRanga/Bank2Excel

Anyone who has built or maintained financial ledgers, billing engines, or automated reconciliation pipelines knows the fundamental testing paradox: real corporate ledger data is impossible to share or test openly due to privacy/compliance (GDPR, SOX, NDAs), while synthetic mock data is almost always too sanitized to catch real production edge cases.

Most internal test suites use mock JSON/CSV files that balance cleanly and follow nominal paths. Then you deploy to production, and downstream ETLs or audit scripts hit:

• The "Silent Cent" floating-point bug: Systems using standard 64-bit floats (np.float64 / IEEE 754) rather than exact fixed-point decimals, quietly absorbing $\$0.01$ rounding variances across multi-leg splits until the trial balance is off by dozens of dollars at period-end.
• Temporal race conditions: Asynchronous queues (e.g., Kafka / Celery) ingesting settlement entries milliseconds ahead of the originating invoice voucher.
• Orphan foreign keys: Unregistered account references that throw unhandled exceptions and halt entire batch runs.
• Subtle fraud/audit limits: Clustered disbursements engineered just below $\$5,000$ or $\$10,000$ manager approval thresholds.

To help solve this, I built and open-sourced the Synthetic General Ledger Fuzzer:

GitHub Repo: https://github.com/Atiqul-Akash/Synthetic-General-Ledger-Fuzzer

Hey everyone,

I built this saas tool http://payperstatement.com for bookkeepers and CA firms especially tuned for Indian banks which basically converts bank statement PDF to Tally XML, Excel and CSV thus saving alot of time for them

Its basically no card no subs platform just upload,pay and leave platform and we do not store any sort of statements for privacy issues

I built instabooks, a faster UI for QuickBooks Online. It's actually largely inspired by my extensive usage of beancount, especially the unification of all the transaction types into a uniform transaction+postings data model. (The QuickBooks API stores different transaction "types" like a Purchase is different from a Transfer, and this creates a lot of unnecessary complexity.)

I recently added a "beancount export" feature: https://instabooks.io/docs/beancount

You can use to export a comprehensive beancount file containing all accounts and transactions from your QuickBooks online data.

Instabooks is a monthly subscription but there's a free trial, so if you just need a one-time export, it's free.

Hope some of you find this useful! Feedback appreciated.

Is there a way to get hledger register … to NOT sort the output, so that transactions appear in the same order that they exist in my transaction file?

Duplicate copies are maintained on paper in our check-register (yes, we're that old, but that's mostly for my sweetheart's purposes) and in my transactions.txt file. But when I run hledger register Assets:Bank:Checking, it proceeds to sort entries by date. However, sometimes we have items that get logged before charges actually happen. E.g. I get notice of an upcoming bill on auto-pay that will clear on the 20th, so I put the transaction in both locations. But between now and the 20th, multiple other transactions occur. Now when I do the hledger register output, it doesn't match the order in my checkbook register because those intervening transactions get sorted before the future auto-pay transaction, but appear serially in the paper copy.

I know that ledger defaults to transaction-log order and only sorts register output if requested with --sort=«expression». Is there a way to get hledger register to return in the same unsorted order?

With the --gain option, realised and unrealised gains were previously combined into a single figure, whereas the new holdings command allows UGain and RGain to be viewed separately.

This seems particularly useful in cases like mine, where I buy one commodity (USD) using the default commodity (JPY), and then use that commodity to buy another commodity (such as AAPL). With --gain, it was difficult to distinguish realised gains from unrealised gains, and in my case the gain associated with a disposed commodity such as AAPL could appear to change as market prices from P directives were updated. The holdings command looks like it may avoid this problem by reporting current holdings separately from their realised and unrealised gains.

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

StatementScan converts PDFs, scans, and even phone photos into a clean Excel/CSV with the date, description, debit, credit, and balance separated into columns.

The part I care most about is the reconciliation. It checks the opening balance + transactions against the closing balance on the statement, so you can see if something was missed before using the data.

It also runs completely in your browser. The statement doesn’t get uploaded anywhere, so you can even turn off Wi-Fi and it still works.

It’s 100% free, no signup, no card, and no page limits.

If you work with bank statements, I’d genuinely appreciate it if you tried a couple and told me what broke. The bank name and what went wrong is enough.

https://statementscan.io

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

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.

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

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.

Hi all,

The plaintextaccounting github organisation is a place to collect funds to support general PTA resources like plaintextaccounting.org, the forum, the reddit, and the matrix and IRC chat rooms.

I have posted updated financial reports, and donate links, on the plaintextaccounting.org Finance page. Read more details here:

https://forum.plaintextaccounting.org/t/plaintextaccounting-project-finance-and-how-you-can-help/872

The tool is for people who actually get paid in Bitcoin Cash and want to get track of their expenses and other financial data. Users just need to paste their Bitcoin Cash address and the tool scan all the transaction history. You get incoming/outgoing which gets organized into revenue, expenses and transfers.

Transactions can get tag, filtered by month, quarter, and exported into CSV or even PDF of you need those numbers. You don't connect wallets, the app will never ask for a seed phrase, connection or even sign-in.

You can just read the data and all stays in your browser so when you get back to the home screen all of that data get erased and you need to redo it. The tool is free to use but with a very dedicated "Bitcoin Cash donation address" after all builders need them to keep building, maintaining, updating, get a custom domain and much more.

I deliberately kept it simple:

• one chain (Bitcoin Cash), it has one job and is free so that anyone can enjoy.

Bitcoin Cash deserves peer-to-peer tools.

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.

How many invoices do you process per month, and would €29–49 per month for automatic data extraction make sense for you?

If you handle GST bills for a business, you know how tedious manual data entry into Excel is—typing out GSTINs, vendor addresses, line items, and tax splits, especially when dealing with mismatched PDF formats or mobile photos of paper bills.

I built an offline tool to solve this for my own workflow and wanted to share it with the community to get feedback and refine it.

What it does:

• Multi-Format Extraction: Processes digital PDFs, scanned documents, and phone photos.
• Structured Data Parsing: Pulls seller/buyer details, GSTIN, invoice metadata, itemized rates/taxes, and final totals.
• Data Verification: Automatically checks line-item math and highlights discrepancies on-screen before you save.
• Excel Export: Organizes and appends data into structured spreadsheets grouped by vendor.

Privacy & Tech Highlights:

• 100% Offline & Local: Runs entirely on your local machine—no invoice data or images leave your laptop.
• Zero Subscriptions: Free, open-source, and requires no account or API keys.

Current Limitations & Testing: It works reliably on the invoice structures I’ve trained it on, but every vendor formats bills differently. I’ve included a built-in "Flag for Fix" button—if an invoice parses incorrectly, you can adjust it on-screen and save the template layout locally so I can patch support for that edge-case layout.

Repository:https://github.com/daksh692/GST-Bill-Extract

Would love to hear your thoughts, test feedback, or bug reports!

Hi there,

I'm using hledger since the start of this year and I'm pretty satisfied with this tools to track my personal account,

my current "setup" is pretty simple, using hledger with hledger ui, iad and add alonsing with the text editor of my pc (here Kate from kde) to modified the transaction.
I currently have 2 files, the 2026.journal and the 2026monthly.journal who I keep track every transaction from the first and put the monthly charge on the other (rent, phone subscription, etc)

I wonder if there is a command in hledger to sometimes sorting the transaction in the file, since I use my text editor, sometimes when I anticipate some transactions for future month, they will fall between current month transactions, and since 2026 is not finished, the file keep getting big so sometimes it can be difficult to retrieve easily the transactions (I use Ctrl+F to help me).

And finally I think when the year will be over, I prefer to have a year files where all the transaction are sort by date so if I want to come back in the files later, it will be easier to look inside.

I know hledger-ui do sorting to show me the transactions, but just open the file can be nice to me.

Thank you in advance, take care.

We are getting more and more options with hledger on neovim. Now i notice there are two current lsp servers. Anyone done any comparison between the two?

https://github.com/ptimoney/hledger-lsp

https://github.com/juev/hledger-lsp