
Show HN: Amatino – A double-entry accounting API - hughjeremy
https://amatino.io/
======
planetjones
I don’t get it. What is the point of being able to push ledger entries to this
service? It isn’t really SaaS, as you’d expect to get reporting and other
stuff. Plus ledger entries are pretty critical for a business and often have
some regulatory requirements, which I am not sure this service could fulfil.

~~~
whatsstolat
In addition ledger entries are the simplest part of accounting. Invoices,
credit notes, tax, etc. are the harder parts.

For ledger entries, create a table and SQL makes a reasonable api. Maybe some
stored procedures for protecting integrity.

~~~
hughjeremy
I humbly disagree, but very much appreciate you taking the time to critique,
whatsstolat! Please allow me to present a counter argument for you to
consider...

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!

------
hughjeremy
Hi everyone - I apologise for linking directly to the Amatino blog, instead of
the Amatino site itself ([https://amatino.io](https://amatino.io)). I deleted
my initial Show HN submission, having thought I posted in the wrong place, and
found I could not resubmit the same URL.

The blog is probably a good place to start anyway, as it shows real
development rather than my marketing-speak!

~~~
icebraining
Can you explain a bit how do you see it being used? I mean, can you describe
an hypothetical application using it?

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!

~~~
voidmain0001
It's an accounting environment, and every system that provides goods and/or
services needs to record the transactions in an accounting system. You can
either use an existing accounting system such as Quickbooks, Freshbooks,
Microsoft Dynamics, but then you're writing a document to those services
rather than the underlying accounts forcing you to define the sales document's
properties in the accounting system. In this case you should be able to keep
your documents (sales invoice/credit memo) internal to your application, and
the underlying account structure. In addition using Amatino should let you
create accounting schedules in your application based off the ledgers. I guess
you would use Amatino where you want more control over your accounting system,
and I would imagine it costs less than the full-blown commercial offerings.

~~~
icebraining
Right, but recording transactions is the easy part; you can even take the
schema from their docs, create a few DB tables from it, and just push to a
local DB.

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.

~~~
voidmain0001
More is required than a db schema; the double entry would have to be in app
logic, permission model, aging, etc. Reports are nice, but in my experience I
have always had to provide additional reporting on top of what is provided by
an accounting system because the business had its own requirements. I see this
being useful where you are trying to avoid a traditional accounting system
because you willing to provide more customization.

~~~
hughjeremy
You put it better than I can, voidmain0001! I've so often been frustrated by
being unable to extend an accounting system to suit my needs.

------
RileyJames
When I worked at Xero we had lots of customers using the API to do exactly
this. That said, I see value in having a api independent and agnostic from the
accounting backend / saas itself, but probably more relevant for larger
integrations (where the cost of switching out the integration would be
extremely costly). This would also be valuable for franchises or software
vendors, who could build the integration once, and then have Amatino handle
the integrations to each accounting system.

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.

~~~
hughjeremy
Wow, RileyJames, thanks so much for taking a look. It's exciting to hear your
thoughts as a Xero alumni. Xero is a big inspiration for me, and I love that
it has made accounting easier for so many businesses.

'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!

------
sudhirj
We needed this to maintain accounts for our B2B products, so we came up with
[https://github.com/RealImage/QLedger](https://github.com/RealImage/QLedger)
\- we deploy the ledger as an internal service (Go+Postgres+Docker) and write
a 'Bank' over it for each business model that we have (two-party /
multiparty). Works great so far, and is pretty solid.

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.

------
WorldMaker
I agree with others that I'm not sure what a SaaS API here helps with without
a lot of existing integrations/bridges to other accounting systems, data
lakes/BI systems, or at the very least a good general UX that provides even
basic human-readable ledgers.

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

~~~
hughjeremy
Hi WorldMaker, thanks so much for taking a look at Amatino. It's very humbling
to know that someone with your experience has critiqued my work!

~~~
WorldMaker
It was only six months experience directly related to this field, for what
little that it is worth. :) I wish you better luck than the project I had
worked on. Accounting is a tough field to compete in, because everyone thinks
they can do it on the back of napkins or in Excel, up until they have to pay a
CPA to tell them everything that they did wrong.

------
nerdponx
How does this work from a security perspective? If I'm an Amatino client, are
you storing my customers' financial data?

~~~
hughjeremy
If you used Amatino as the double-entry layer of your product then yes,
Amatino would be storing your customer's financial data. My aim is to make
Amatino a very low-level service, akin to an Amazon S3 for double-entry data,
wherein people are comfortable building products on top of it. (A very tough
goal, I know!)

------
sciurus
In your roadmap I see "Deploy to multiple global cities based on public
feedback and demand" and "Complete global deployment in all practicable global
cities"

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?

~~~
hughjeremy
Thanks for taking a look at Amatino, sciurus, I'm so excited that you got so
far as the roadmap!

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.

------
rcdwealth
I would not know why would anybody wish to give their accounting information
to any online company, distant, unknown.

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](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!

~~~
hughjeremy
rcdwealth, it might sound crazy, but on a personal level I agree with you!
Amatino was born out of my own frustrations with existing "cloud accounting"
and the implications for my data.

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.

------
oftenwrong
I don't think I understand this. Isn't the double-entry more of an
implementation detail?

Instead of...

    
    
      entries: [
        Entry(side: .debit, account: cash, amount: Decimal(42)),
        Entry(side: .credit, account: revenue, amount: Decimal(42))
      ],
    

...you could have:

    
    
      debitAccount: cash,
      creditAccount: revenue,
      amount: Decimal(42)
    

In other words, why does the client need to care about multiple entries in the
call. I just want to record that X amount was sent from account Y to account
Z. You can atomically record that as two entries in the back-end.

~~~
sgmoore
A single transaction should not be limited to just two nominal codes. For
example, an invoice/payment might be split between Hardware, Software, Haulage
and Tax/Vat and the other side would be the bank account. You also don't want
to see multiple entries on your bank nominal when there was only one actual
payment.

~~~
hughjeremy
Exactly :) - Each Transaction can have (arbitrary limit) 100 entries in
Amatino.

------
kowdermeister
As a complete accounting noob, why should I use this?

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? :)

~~~
hughjeremy
Hi kowdermeister! Thanks for taking a peek at Amatino, I'm super excited to
answer your question, I'll try to keep it brief...

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!

~~~
kowdermeister
Thanks for taking the time to answer, but I don't get why should I opt-in to
double entry bookkeeping. For someone who wants to build a side-project this
is the last thing I want to think about.

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.

~~~
hughjeremy
Oh! I see, I apologise, I may have misinterpreted your question. Amatino would
be applicable to someone who is building a project that needs double-entry
bookkeeping to function. For example, they might be a fintech startup building
an early invoice payment trading platform. Rather than building their own
double-entry layer, they could leverage Amatino.

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.

------
deedubaya
Soooo many startups don't have solid accounting implemented in their money
handling applications. Double entry accounting has been around for a long,
long, long time, making it easy to reconcile account balances. It's just a
matter of implementation.

~~~
hughjeremy
deedubaya, I couldn't agree more. Some of the accounting implementations I
have come across have made me want to barf. It is my dream that Amatino will
make it easy for businesses to develop robust, performant, flexible accounting
systems.

------
fiatjaf
Very good idea, but the documentation is not very intuitive.

~~~
hughjeremy
Thanks fiatjaf! The documentation definitely needs work. And worse, it only
documents HTTP interactions, not the rapidly expanding client libraries! Do
you have any examples of documentation you really like? I'm a big fan of
Stripe's but I'm not sure if I can replicate that level of quality quickly.

~~~
fiatjaf
Ok, actually I don't think the documentation needs to be improved a lot, I
think you can get 1000% better if you add a "quick start" guide for
developers. Just a small page with examples so they get the feel of it. Then
they can consult the full reference if they need do to anything else.

For example, [https://strike.acinq.co/documentation/get-
started](https://strike.acinq.co/documentation/get-started) and
[https://developers.trello.com/docs/api-
introduction](https://developers.trello.com/docs/api-introduction)

~~~
hughjeremy
Nice, thank you so much for those examples, fiatjaf! I actually already had a
'getting started' page ([https://amatino.io/articles/getting-
started](https://amatino.io/articles/getting-started)) but it is nowhere near
as good as those ones you've linked. Plus it obviously is not easy enough to
discover! I'll review those examples and try to lift Amatino up to their
standards.

PS - Strike's page is so nice! Hnnnggg. Love the little diagram.

------
thieving_magpie
The pricing is attractive. It's low enough that I would consider prototyping
against it to see if it'd work for a future project.

~~~
hughjeremy
Ahhh! thieving_magpie your comment made me so happy! I'd be thrilled to help
you tinker with Amatino, if you ever do proceed to give it a go.

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.

