Amatino is trying to sit at a lower-level of the value chain than reporting, GUIs, and other layers. Amatino aims to enable others to create amazing reporting and GUIs, while charging them an extremely low price to do so.
For ledger entries, create a table and SQL makes a reasonable api. Maybe some stored procedures for protecting integrity.
In my opinion, ledger entries are the hardest part of accounting. Invoices, etc, are all supersets of double-entry accounting, and can be reduced to collections of entries if the underlying double-entry system is sufficiently robust, generic, and and capable.
Such a system should be able to, for example, recursively sum entire account trees, while transparently translating (instantly) across heterogeneous units of account (e.g. stocks, currencies, cryptos, intangibles), and do all that on any device, on any platform, at any time, anywhere on Earth, on demand.
I know this sounds crazy - Sometimes I think I am crazy! Across the world, between companies, and even within Big4 accounting firms, there are infinite ways of constructing an 'invoice' or a 'credit note'. Everyone has their preferred way, none being right or wrong.
Amatino aims to sit below that level - Allowing developers to create their accounting system their way. No compromises.
Again, I really appreciate you looking, even if you think Amatino isn't a worthwhile project. Pondering this reply was in itself a very valuable exercise for me, so thank you for taking the time to comment!
The blog is probably a good place to start anyway, as it shows real development rather than my marketing-speak!
The impression I get from the site is that you're essentially a hosted database with a predefined schema, but I'm guessing there's more to it.
Good luck on the project!
The reason to use a real accounting system is for the extra features (mainly reports), but I don't see them in this API, so you'd still need to export your data to one of those systems. So I'm struggling to see the advantage of pushing data to their service rather than to a local DB.
More time spent developing awesome applications, less time spent (for example) developing logic to recursively sum accounts in multiple currencies.
I see Amatino used as the unsexy, unsung, unseen double-entry data layer for other apps. Perhaps those apps are fancy GUI accounting apps like Xero, perhaps they are in-house bookkeeping systems, and so on.
Amatino saves the developers of such apps from having to develop their own double-entry systems, and provides them with a rich feature-set to draw on.
The primary issue becomes ensuring the integration to the accounting systems stays high value, rather than lowest common denominator. Ie: ensure reports are usable, accounting records are in a usable format (invoices, credit notes, etc rather than a bunch of journal entries), payments are applied, bank accounts can be reconciled. If that can be nailed I feel this has value.
'Independent and agnostic from the accounting backend / says' is exactly what I'm going for, and I'm really excited to hear that you see some value in the concept. I'll take your advice to heart!
Would love feedback. We haven't yet hit the scale where postgres can't sum up the transactions in time and we need to maintain caches, but we're willing to look at ideas for that.
Also, as an API design it seems to leak abstractions that the client should maybe not worry about. If the goal is to help applications do proper double-entry accounting, then it should provide means to add transactions without knowing the gritty details specific to entries.
Aside: I worked on API side of double entry accounting program once, long ago. In college I was an intern on Microsoft Small Business Accounting (which was renamed/rebranded towards the end of while I was there to Office Accounting). It's a shame that product was cancelled, as it was good product with proper double-entry, good reports, and a great API (even despite my major attempted improvements never making it into the product before it was cancelled ;).
This sounds like it could be a huge waste of time compared to investing in other areas of the product. How have you determined that your customers care where your service is hosted?
In "MVP" testing, I found that one of the critical problems with the service was latency. Amatino was used as the data layer for a GUI accounting application. When the service was running ~200ms+ away, the application spent too much time doing 'loading spinners' and the user experience began to suffer.
This experience led me to adopt a distributed design, that allows Amatino to sit as close as possible to end users.
Fortunately, deploying to a new region is as simple as running one script, the process is fully automated. So I don't have to worry about trading time on investing in other areas of the product.
So people don't do it.
Imagine, your own accountant knows everything about you. Hyr knows your suppliers and your buyers, he has close insight in your business. And you need to be careful with him.
Best is if you can handle your accounting yourself. There is free software for that like https://www.gnucash.org and others. There is also online free software, which you can install on your intranet.
Do not install your accounting online. Internet is not for doing your private business.
And do not give your accounting data to anybody online.
Come back to basics and keep your business private!
I am a die-hard GnuCash fanatic!
In the end, I came to the conclusion that many people want to store their data online. Whether it is their intimate photos, medical history, or bank statement. Yet some services do not meet this trust with discretion. That angers me, upsets me, and gets me fired up to write good code.
I want to give those people a way to store their financial data that is up to my paranoid privacy standards. Privacy has informed a lot of design decisions in Amatino, often to the detriment of performance or features.
I'm starting to blab on - I'd love to continue this thread though! Privacy is issue #1 for me and I would happily chat about it all day.
Entry(side: .debit, account: cash, amount: Decimal(42)),
Entry(side: .credit, account: revenue, amount: Decimal(42))
How is this supposed to help me instead of listing the transactions from my own sales_history table of my local DB?
Do I need to create a GUI for your service listing the transactions?
Let's say I implement your service. You have all transaction data, fine, then what? :)
In my fantasy land, Amatino has replaced your 'sales_history' table completely, from an accounting perspective. As your business grows and your needs grow more complex, you would make calls to Amatino rather than developing new internal solutions.
For example, perhaps your sales_history table is implicitly denominated in Euros, but you expand into the US and now need to store U.S. Dollar amounts. In Amatino, you could instantly create a USD revenue account, and proceed to view a combined balance of all revenue accounts.
The time you would have spent dealing with manipulating double-entry data instead goes into making your product more awesome.
Obviously Amatino has a long way to go to earn that level of trust!
Also, if you track sales in euros and dollars, then how do you track the changes in the exchange ratios?
What about rest? What happens to the data you aggregate? It just sounds like more work for me to make it available to my accountant.
If double-entry accounting only exists in your project insofar as you need to account for your own business, then, as you say, Amatino would probably be an excessive solution creating unnecessary work.
Aside, on the topic of exchange rates - Amatino has built in daily exchange rates between each of 36 major currencies (You can also feed it your own, if you want more resolution / different units of account). It also automagically computes unrealised gains and losses.
For example, https://strike.acinq.co/documentation/get-started and https://developers.trello.com/docs/api-introduction
PS - Strike's page is so nice! Hnnnggg. Love the little diagram.
I'm so glad you find the pricing attractive. I've devoted a lot of effort building the system in a cost effective way, so I can keep the price down.