I don't see how this is actually a use-case. How many people that need accounting software do it from the terminal? And on what earth is that a worthwhile business decision to spend time and money on this?
being able to maintain local backup/copies of your entire general ledger, even if u are using a cloud tool is generally the #1 blocker for any accounting team.
Instead of building a whole new format (with implications on testing, etc) - it would be incremental effort to build support for ledger-cli format . And completely mitigate 90% of the objections by accounting teams.
I understand. But this is not a proper journal file imho. We're actually building something in this space as well and there are way better but probably local standards like the Datev format (essentially CSV). Accountants need double book formatted journal entries. This is just a collection of amounts it seems.
But I really appreciate all the different solutions in this space! I build our own when we started.
If "better" incorporates "battle-testedness" and portability, I'd advocate for considering Ledger's format. (Or beancount's. It's almost identical and has more accessible FOSS parsers + generators)
It's about as minimalistic as you can get while still incorporating legibility and flexibility to support arbitrary transactions (including in commodities, etc.).
I say this as somebody who voluntarily wrote a parser and generator for their format, as a happy user, and without being affiliated with the project -- it's quite good!
No, better actually means more than hobbyist accounting with publication obligations. While I think it's a cool tool, for proper (German/European) accounting you'd need tax quotas, reverse charge taxation, compatibility with SKR04 most likely (your tax consultant uses that in > 90% of the cases). You'd also need different dates for each journal entry: invoice date, date of service and booking date, booking notes, links to the invoice/contract causing the accounting event (that's mandatory) and a whole lot more.
So I think our requirements are a tad more complex than ledger can support. We are compatible with the German DATEV format. DATEV is the accounting software and we don't wanna replace it. I could write a whole lot about that but I'll spare you that. Let me just say that we have good reasons to have our own format of accounting internally and there's no benefit in supporting ledger. I don't think there's even one person in the world that is a) our target persona and b) uses ledger.
Well, I'm not going to tell you what's good and bad for your business, but for what it's worth Ledger supports all of those things. Whether it's right for your business or not is up to you and your customers, but you're selling Ledger short by describing it as "hobbyist accounting".
Tax quotas, reverse charge taxation, the various date types, notes, links are all totally supported with Ledger's primitives as they are. SKR04 just looks like a list of account classifications, which is totally fine. You can either make that 1:1 with the account list you use, or you can tag entries in a transaction with metadata indicating that it's associated with that SKR04 classification.
Again, not attacking your decision to use your own format, it's the right choice in many situations. But ledger is literally the primitives of accounting – it's up to you to superimpose your system of rules and regulations on it, but since it's just double-entry accounting with metadata and tags, it almost certainly can.
Here's an example transaction, where somebody pays $20.00 for 20 tons of scrap metal, with links to the invoice, an invoice and transaction date, a mark to indicate that it's settled, and a $8 VAT liability that accrues at the end of the month.
2021-01-01=2021-01-03 * ACME Supplier
; invoice_num: 123
; invoice_link: https://invoices.widgetsandthings.de?id=123
; service_date: 2021-01-02
; notes: John said he'll charge us more next year.
Liabilities:CreditCards:Chase:XXXX $-20.00
Liabilities:Taxes:VAT $-8.00 ;[=2021/01/31]
; reverse charge tax, accrues at end of month
[Quotas:Tax:VAT] $8.00 ;[=2021/01/31]
; you'd use a "virtual" account to express "quotas" or "budgets".
Expenses:ScrapMetal $28.00
; I'm bundling the VAT and metal expense into a single entry.
; But if you wanted to record them separately, with their own effective dates, you can.
Assets:ScrapMetal 10 tons ; skr_code: SM2201 (I'm making this up)
Receivables:ScrapMetal -10 tons
Nice, I appreciate that, thank you so much! As I said, ledger looks cool and I might play with it just for the fun of it. But as far as I can see it's file based, right?
We obviously keep our accounting data in databases and only support exporting to DATEV atm, hence the compatibility with that format. The point of our whole endeavour is to *not* do accounting. You process your documents and we use OCR and simple input from the user to create the correct journal entries. Your tax consultants and accountants work in the background to review everything and export that into their systems to continue working on that. That's necessary for all the publications and tax reports you need to do in Germany/Europe. You can think of us as a pre-accounting software. A nice input layer. It's more about the bigger picture. Think multiple companies, real estate. You get a real time overview of your finances. You get banking integration. You can collaborate, with your employees, your family, notaries, lawyers, tax people and accountants. So accounting is just a side-effect for the user. Having a real time overview of a more complex financial setup is the USP.
Having said that, I don't see a real value to support import/export of the ledger format for now. Our first persona we're targeting aren't people that do their accounting themselves.
Correcto, it's meant to live at-rest in plain text files. When you exec the `ledger` binary, you point it at a collection of ledger files, and it parses them into memory to perform whatever operations you request (report generation, etc.).
It's written in C++ and scales about as well as you'd imagine (i.e. mainly a function of memory constraints).
It sounds like exporting to DATEV is the right choice for your customers and region.
The benefit of a format like ledger is that it's universal and relatively trivial to write your own parser for. Most accounting software packages might not import ledger files natively, but there's probably a ledger -> $your_format converter out there – if not, it's generally trivial to write one. It's kind of like how "markdown" became a common language for latex-generated PDFs, HTML, and powerpoint slides thanks to Pandoc. Ledger doesn't quite have a pandoc-style tool yet, but `.ldg` files are basically the accounting equivalent of markdown or HTML.
I will defer if you are indeed building your own competing tool in this space which is better, but holding to the original point of my request - maybe it will be incremental to support your format if ledger-cli format is supported today. versus not supporting any disk format (or inventing a new one).
