Announcing indiAccounting 1.9: Non-Profit Support, Foreign Currency, and a Chart of Accounts That's Finally Yours

indiAccounting 1.6 was about everyday bookkeeping — the bank register, printed checks, payroll that handles real life. Since then the app has quietly picked up freight and shipping on orders, early-payment vendor discounts, and a CSV importer that brings whole sales and purchase orders across from other systems.

1.9 is about something different: the assumptions underneath the app. Out of the box, an accounting program assumes you’re a for-profit business, that you sell in one currency, and that its chart of accounts is the one you’ll live with. This release removes all three assumptions — and much of it came directly from conversations with people using the app, including two non-profits who arrived within a fortnight of each other.

Here’s what’s new.

Run a non-profit? The books speak your language now

Set your Entity Type to Non-profit and the wording changes throughout: Statement of Financial Position rather than Balance Sheet, Statement of Activities rather than Profit & Loss, Change in Net Assets rather than Net Income, and donors rather than customers. These aren’t cosmetic preferences — they’re what the statements are actually called, and a report headed the wrong thing is one a treasurer has to explain at every board meeting.

There’s also a non-profit chart of accounts, offered at company setup and any time afterwards from Settings. It renames the owner and sales accounts to net assets and contributions, tucks away the trading accounts a charity never touches, and adds Grants, Fundraising Events, In-Kind Contributions, and Membership Dues. It creates Program Services, Management & General, and Fundraising as classes rather than accounts — because one salary is split across all three, and that’s what makes a Statement of Functional Expenses possible down the road.

It’s safe to run on books you already have: anything you’ve actually used is left exactly as it is, and the app tells you what it renamed, added, hid, and what it left alone. Every part of it is something you could do by hand, so every part can be undone the same way.

One deliberate line we didn’t cross: invoices are not renamed to pledges. An invoice is a request for payment whoever sends it; a pledge is a promise to give — a different document, not a renamed one — and calling one the other would misdescribe your own books.

And a preview of what’s next: proper donor restriction and fund tracking — recording that a gift was given for a purpose, how much of the building fund is left, and releasing restrictions with real journal entries — is fully designed and on the roadmap. If that’s the feature that matters to your organization, tell us; it moves up the list.

Your chart of accounts, your numbers

If you’ve come from another accounting package, you probably have a numbering scheme you’ve used for years — 1-1000, 2-1000, that sort of thing. Until now, the built-in accounts were stuck on our numbers, so half your chart read in your scheme and half in ours.

In 1.9, every account can be renumbered — built-in or not. The app now records what each built-in account is used for separately from what it’s numbered or called, and every automatic posting and report finds it that way. The number is yours. Renumber the entire chart and everything keeps posting and reporting correctly. (If a number is already taken, the app tells you which account has it, by name.)

Two companions to that:

Hide accounts you don’t use. A service business has no use for Inventory Asset; a charity has no use for Cost of Goods Sold. A built-in account that has never been used can now be hidden, dropping it out of every picker. If a hidden account ever turns out to be needed, indiAccounting brings it back rather than refusing to post — tidying up can never break your bookkeeping.
Revenue lands where your catalog says. Products and services have always had an income-account field; now every sale actually honors it. Set up separate income accounts for your revenue streams and your P&L shows them as separate lines, automatically, with no journal entries after the fact.

Invoice in euros, keep your books in dollars

An invoice or bill can now be raised in another currency. The document stays in the currency you billed in; your ledger stays in your own currency, always. Each document stores the exchange rate as of its own date, so what it posted can always be reproduced — even after the rate moves.

And when the rate does move between invoicing and payment, that difference is real money. indiAccounting posts it as a realized exchange gain or loss to a new account, 4900 Foreign Exchange Gain (Loss), automatically, on both the sales and purchase side.

Two honest limits, stated plainly: bank accounts stay in your home currency, so a foreign invoice settles into a home-currency account. And open balances aren’t revalued at period end — gains and losses are recognized when a document is actually settled. If everything you do is in dollars, nothing changes for you at all.

When something happens to the file itself

Your books live in a single file on your own machine — that’s the whole point of indiAccounting. But files can be damaged by things no app controls: a copy taken while the app was running, a disk that failed mid-write, a folder moved between machines by hand. The frustrating part is that damage like this can sit unnoticed for weeks and then surface as one feature mysteriously failing.

1.9 takes responsibility for this. The app now checks your file at startup, and Settings → Export & Backup gains a Database Health section with a thorough check and a plain-language report. Damage confined to the indexes is repaired in place with nothing lost. Deeper damage is salvaged into a fresh file, table by table, recovering everything readable — and telling you exactly what couldn’t be recovered rather than presenting a partial file as a whole one. Any corruption error anywhere in the app now explains what happened and where to go, instead of quoting database internals at you.

The same release documents the safe way to move your books between machines (backup and restore, not file copying) — right in the app, with the reason why.

Imports that can run themselves

The order importer grew up in 1.9:

Importing the same file twice no longer creates duplicates. Each imported document remembers where it came from; a repeat is simply skipped and counted as such. It’s judged per document, so an incremental export with a mix of old and new rows brings in just the new ones. Re-running an import after fixing a column mapping is now a safe, ordinary thing to do — which is exactly what a first migration from another system looks like.
A command-line importer installs with the app. Point it at a file and a saved mapping and it imports unattended — on a schedule, or fed by another system. It uses the same importer and the same posting rules as the screen, so there is no second way into your books.
Expected date and Ship Via are now mappable on imported orders, and Ship Via carries from a sales order onto the invoice raised from it.

Watching an economic-nexus threshold

If you sell into a state where you’re below the economic-nexus threshold, you charge no tax there — but you have to watch what you sell there, because crossing the threshold starts the obligation. That’s what a 0% tax jurisdiction is for, and as of 1.9 it works exactly that way: sales into it accumulate on your Sales Tax Report with no tax charged, so the number you need to watch is right there.

While we were in that corner of the app, we clarified something that confused a careful tester (thank you, you know who you are): a jurisdiction’s rate field is a published-rate reference, not what gets charged — charging requires a Tax Rate pointing at the jurisdiction. The field is now labeled that way, and the jurisdiction list flags any jurisdiction no tax rate points at, so a half-finished setup can’t sit silent.

Fixes

Real testing by real users found things worth fixing, and we’d rather fix and say so than stay quiet:

Applying a credit note to an invoice now sticks — recording a later payment no longer brings the credited amount back as owing.
Voiding a paid invoice refunds each payment to the bank account it actually arrived in, keeping both accounts reconcilable.
An invoice raised from a sales order takes its due date from the customer’s payment terms, not the day it was raised.
Negative amounts can be typed into a line again, so credit lines and corrections work the way the ledger always intended. (The minus goes on the price; quantity stays positive so a pricing correction never moves stock.)
The currency selector on invoices and bills now saves — it’s what grew into the full multi-currency support above.
Vendors created by the order importer can be edited normally, and the early-payment discount you set up on a vendor is now offered when paying from the bills list, not just from the bill’s own page.

A word about upgrades

A buy-once app that keeps your books in one local file owes you a careful upgrade path, and 1.9 raises our own bar. Every release’s upgrade is now tested against the actual database schemas that shipped in 1.6, 1.7, and 1.8 — not approximations — with automated checks that every table, column, row, and balance comes through identical, that the ledger still balances to the penny, and that a fully populated company file can run a complete business day after upgrading. Your books upgrade automatically on first launch, and nothing about them is touched beyond what the release notes say.

How to get it

1.9 is a free update for all license holders. Download for Linux & Windows, open your books, and you’re upgraded in a couple of minutes.