This i found very enlightening to read. I wonder how many accounting apps actually store their data as he describes in this article, to aid their calculations
There are some further complications that make it impossible to use that exact representation without change; for instance a single transaction may involve more than two nodes; you could buy furniture and computers in one transaction and something in the system needs to represent this was one purchase, even if it is further broken apart after that. But with suitable modifications it seems like this ought to work. Whether or not it is actually done this way, I don't know... and to be honest, I doubt it, filed under "I don't need all that theory crap, I've got problems to solve!". Programmers are often quite happy to write much more complicated and redundant programs if it means not having to learn about graph theory. Not that they think of it that way. And I find it unlikely anybody started a real accounting project with "First, let's learn all about accounting and strip it down to the minimal conceptual core", rather than "Our accountants say this is how it works, so let's start putting together the matching class hierarchy", which will not produce a clean graph structure where one did not previously exist.
(And yes, theory can't be perfectly followed either, all systems will generally need some amount of dirty things, but the correct balance IMHO is definitely not 100% "pragmatic".)
Accounting programs already employ such directed, weighted hypergraphs. They are just not storing pretty pictures, but the incidence matrix.
The programmers probably don't think of their tables as an incidence matrix though, and end up coding lots of special cases, instead of re-using general graph algorithms.
(And yes, theory can't be perfectly followed either, all systems will generally need some amount of dirty things, but the correct balance IMHO is definitely not 100% "pragmatic".)