In order to effect control of any system we must first have data on that system. A planned economy, such as I've been writing about for the last few years, is synonymous with economic coordination in kind. For such coordination to not be completely arbitrary, to devolve into subjectivist nonsense, we must have accurate in-kind data. Accounting in kind, accounting in physical terms, can be used to gather such data. What we do with the data once gathered, and what data is sensible to gather in the first place, can be debated. But what is certain is that we cannot provide guarantees that the human economy is kept within environmental bounds, while fulfilling human needs, without having some idea of what each part of the economy is doing.

In-kind accounting can be used not only to track production, but also for inventory, transportation and for detecting theft. The unloading of a container from a ship is an accounting operation, as is the further transport of that container. The container is "created" when it is packed at the source and "destroyed" when it is unpacked at the destination. As accounting maneuvers the creation step can be booked as crediting a "containers in flight" account and debiting the container to wherever it will picked up from. Once the container is unpacked at its destination it is credited from the destination and debited to the in-flight account, making all accounts associated with the container sum to zero. As long as the container is in flight it appears on the books as a liability. If the container is lost, whether by accident or by theft, that too can be booked as a transaction to some appropriate account.

When workers at a warehouse perform inventory, any discrepancies between expected and actual inventory can be accounted for by debiting and crediting relevant accounts. For example, if the books show that there should be ten tons of gold in a vault but there are only nine tons, then this can be booked by crediting the warehouse one ton of gold and debiting a discrepancy account one ton of gold. Obviously such a discrepancy would be very serious and grounds for investigation, but it should first of all be accounted for. Another example could be a tank car of methylamine showing a mass discrepancy between source and destination. Unusually high or low yields in certain manufacturing processes could also be detected, by performing statistical analysis on the in-kind accounting data.

Some time after I started writing this post I was sent a 2007 paper by David Ellerman^[3] that talks about vector-valued in-kind accounting. I will use Ellerman's terminology where appropriate.

Ellerman's analysis

To get us started I will repeat what Ellerman says.

T-accounts and the Pacioli group

Accounts in traditional accounting are called T-accounts, due to their table borders often being drawn in a way that resembles the letter T:

Debit	Credit
d	c

Ellerman points out that traditional double-entry accounting forms what in mathematics is called a group^[3], specifically a so-called group of differences. He names this group the Pacioli group after the Franciscan friar Luca Bartolomeo de Pacioli, who first described double-entry accounting in his 1494 text Summa de Arithmetica^[6]. Ellerman chooses the symbol $\mathbb{P}$ for elements of this group, which is equivalent to ${\mathbb{N}}_0^2$, the set of pairs of non-negative integers. Following Pacioli, he denotes elements of $\mathbb{P}$ like this:

$[d//c]$

where d stands for debit and c stands for credit. Ellerman names these elements T-terms. Ellerman defines the identity element of $\mathbb{P}$ as $[0//0]$. He defines addition pairwise like so:

$[w//x]+[y//z]=[w+y//x+z]$

Equality is defined by what Ellerman calls the cross-sum:

$[w//x]=[y//z]\iff x+y=w+z$

Finally, Ellerman defines the inverse of an element of $\mathbb{P}$ as simply swapping c and d, and shows that adding the inverse of an element to itself results in the identity element, which is a must for an abelian group:

$[y//z]+[z//y]=[y+z//y+z]=[0//0]$

Ellerman calls any T-term that is equal to $[0//0]$ a zero-term, and points out that any balanced transaction is a zero-term. A journal is a list of such balanced transactions, the sum of which is also a zero-term.

Ellerman points out that the "double entry" in double-entry accounting doesn't refer to the two columns debit and credit, but to the fact that any modification to an equation must affect at least two terms of that equation if the equation is to hold. This observation goes back to at least Muhammad ibn Musa al-Khwarizmi, from whose work al-Jabr (completion/rejoining/balancing) we derive the word algebra. The concept is likely as old as mathematics itself.

The double entry principle applies also when using a single column of signed values to record things. Compare the following two methods of recording a transaction of 1000 units from account Bar, and 250 units from account Floop, to account Foo:

Account	Debit	Credit
Bar	0	1000
Floop	0	250
Foo	1250	0

Account	Amount
Bar	-1000
Floop	-250
Foo	1250

In the first table we need the sum of all entries in the debit column to equal the sum of all entries in the credit column. In the second table we need the sum of all amounts to be zero. Ellerman points out that either approach is valid, and that they are in fact equivalent^[3]:

The real choice between the double entry method and the complete single entry method of recording a transaction is the choice between using unsigned ("single-sided") numbers in two-sided accounts or signed ("two-sided") numbers in "single-sided" accounts.

Multi-dimensional accounting

In a 1986 paper Ellerman extends the above concept to vectors of non-negative integers (${\mathbb{N}}_0^n$), and more generally to vectors of non-negative reals (${\mathbb{R}}_{\ge 0}^n$)^[2]. The formulation is entirely the same as the scalar case, only with vectors instead of scalars. For example, the identity element is defined as $[(0,0,\dots 0)//(0,0,\dots 0)]$.

Taking the previous example, let us pretend it concerns the sale of some gizmo at a price of 1000 + 25% VAT. Ellerman calls the money and gizmos two properties that are to be accounted. Let us extend the example to two-dimensional vectors with properties $(\text{Money},\text{Gizmos})$, using Ellerman's notation:

Account	[Debit // Credit]
3001 Sales	[(0, 1) // (1000, 0)]
2610 Outgoing VAT, 25%	[(0, 0) // (250, 0)]
1930 Company account	[(1250, 0) // (0, 0)]
9001 Inventory	[(0, 0) // (0, 1)]

The four-digit numbers are taken from the standard Swedish account plan (kontoplan). The entire 9XXX range is reserved for internal accounting, so I use that for inventory. I have chosen to account the debit of the gizmo to the customer via the sales account. We can see that the sales term represents C-M exchange (commodity-money). The entire transaction sums to $[(1250,1)//(1250,1)]$, which is a zero-term, as required for a transaction.

Single-sided multi-dimensional accounting

Ellerman doesn't go into single-sided (signed) accounts in his 1986 paper, so I will demonstrate the concept here. By subtracting credits from debits we arrive at the following:

Account	Amount
3001 Sales	(-1000, 1)
2610 Outgoing VAT, 25%	(-250, 0)
1930 Company account	(1250, 0)
9001 Inventory	(0, -1)

In the above it isn't immediately obvious what is being accounted for. By moving the properties into the table header and splitting them up into two separate columns we get the following:

Account	Money	Gizmos
3001 Sales	-1000	1
2610 Outgoing VAT, 25%	-250	0
1930 Company account	1250	0
9001 Inventory	0	-1

I find this far easier to read compared to Ellerman's notation. With double-sided accounts it would look something like the following instead:

Account	Debit		Credit
	Money	Gizmos	Money	Gizmos
3001 Sales	0	1	1000	0
2610 Outgoing VAT, 25%	0	0	250	0
1930 Company account	1250	0	0	0
9001 Inventory	0	0	0	1

The benefit of the above is that it is closer to what traditional accounting looks like. But it is also more verbose. Personally I prefer the single-sided (signed) version.

Non-exchange

The exchange of gizmos for money is value-preserving, assuming general equilibrium. In an economy without exchange, for example a gift economy, value is not preserved. If for example, instead of selling the gizmo, it is simply given to other entity, the transaction simplifies to:

Account	Gizmos
9001 Inventory	-1
6993 Gifts	1

If both entities do their accounting in a common system then the transaction may look like this:

Account	Gizmos
9001 Inventory A	-1
9002 Inventory B	1

There is no counter-flow of value here. The transaction is akin to a requisition. This is the case with the free gifts of Nature, in all modes of production. Nature should therefore have an account in an in-natura accounting system. In contrast, Ellerman says the opposite^[3]:

For example, production is often viewed as an exchange with Nature where the inputs are the property given up to Nature and the outputs are the property acquired back from Nature. This metaphor may be helpful for illustrative purposes, but 'Nature' will not be awarded an account in property accounting.

But if for example we dig up coal, that coal has to be credited from somewhere in order to enter into the in-kind accounting system. It therefore makes perfect sense to credit Nature for it. An account for socialist primitive accumulation would likely also be necessary for similar reasons.

The historical reason for unsigned accounts

Traditionally accounting is done using double-sided unsigned accounts, as explained above. I suspect that this method comes about for historical materialist, technical reasons. It is much easier to sum two columns of unsigned numbers separately and then computing balances, than it is to sum single columns of alternating positive and negative numbers. This is the case when adding numbers by hand, but also when using certain adding machines. Only with the advent of full computerization has the mixed adding of positive and negative values stopped being much of an issue. The material need for unsigned accounting has therefore disappeared.

Rational-valued accounts

In Ellerman's analysis accounts are either integer-valued or real-valued. While we in theory could transfer $\pi$ units of something between accounts, such accounting requires symbolic manipulation. This is impractical, so I will not consider it further. There is however a practical need for non-integer accounting, and I will make the case here that arbitrary precision rational numbers can meet this need.

Consider accounting grain shipments. While in the best of worlds everyone would use the same system of measurement, be it metric or imperial, in practice there is a mix of measurement systems and devices in use. If we used integer values, agreeing on some common denominator in the system, then as soon as an amount of grain measured using a system which doesn't neatly fit into the agreed-upon denominator, that entry would either have to be quantized into the current denominator, or the denominator would need to be changed. Quantization means a loss of information, which is undesirable in an accounting system. Changing the denominator is possible, but involves retroactively changing all previous transactions involving that property. Such changes are also costly to perform in a large database in an atomic manner. Therefore a rational-valued accounting system is a practical solution.

Let us presume the long ton is used for tracking shipments of grain. The transfer of one long ton of grain from point A to point B is then simply

Account	Grain (long tons)
Point A	-1
Point B	+1

Let us now presume that a transfer of one metric ton is to be added to the system, for example from C to B. While the long ton is exactly 0.997903214 metric tons ($2*7*{11}^2*97*6073$ mg), a metric ton is only approximately 1.00210119175 long tons. It is however exactly 500,000,000 / 498,951,607 long tons, so let's add that to our rational-valued accounting system because we can:

Account	Grain (long tons)
Point C	-500000000/498951607
Point B	+500000000/498951607

Assuming there was no grain at point B initially, there is now (as far as the accounting system is concerned) exactly 1 + 500,000,000 / 498,951,607 = 998,951,607 / 498,951,607 long tons of grain at point B. While this is unwieldy for a human to keep track of, it is no problem for a computer. An interesting thing happens if we transfer another six metric tons to point B, say from point D:

Account	Grain (long tons)
Point D	-3000000000/498951607
Point B	+3000000000/498951607

The total amount of grain at point B is now 3,998,951,607 / 498,951,607 long tons. But because $gcd(3998951607,498951607)=7$ we can simplify this to 571,278,801 / 71,278,801.

Uncertainty

One issue with the above example is that it gives the impression that we have nine digits worth of accuracy in the original data. In reality the figure of one metric ton may come from a scale with two digits of accuracy, so there's really anywhere between 0.99 to 1.01 metric tons of grain. The scale might also not be calibrated correctly. The moisture content of the grain will change over time, affecting its mass. For these reasons it might be useful to also account for uncertainties. The grain stored at point B might not be reported as a single value, but as an interval, tracked by two accounts rather than just a single account.

On properties

As stated earlier, Ellerman calls the dimensions in his multi-dimensional accounting system "properties". The name comes about from the need for firms to track what actual property they have, rather than the value of said property, which is always in flux. Not doing so gives rise to what Ellerman calls "valuation controversies"^[2].

Take for example foreign currency. In many firms such currencies are accounted in the local currency and, if using the invoice method of accounting (fakturametoden), they are booked twice: once when an invoice is sent, and a second time when the invoice is actually paid by the customer. Any discrepancy in exchange rate is booked in a special account for that purpose. In the Swedish account plan these are account 3960 Valutakursvinster på fordringar och skulder av rörelsekaraktär, or account 7960 Valutakursförluster på fordringar och skulder av rörelsekaraktär, depending on if the change in exchange rate is a gain or a loss. Very rarely are the actual foreign currency amounts actually booked.

The types of properties we might choose to account for can be quite numerous. For example we might track all of the following:

• yards of linen
• number of coats
• cubic meters of potable water
• cubic meters of gray water
• euros
• hectares of land
• troy ounces of gold
• hogsheads of kerosene
• number of RC0402JR-0710KL 10kΩ 5% 1/6W 0402 resistors
• number of 40 foot ISO containers
• number of 40 foot ISO containers with serial number #1234 containing 100 bicycles of model X
• number of 40 foot ISO containers with serial number #4321 containing 100 bicycles of model Y

These are all quantifiable use-values. We obviously cannot account for things that aren't quantifiable, like a beautiful sunset.

It should hopefully be apparent that there is a limit to what amount of detail we might bother accounting for. That question has to be worked out in historical time. For now I am content with recognizing that there will be some cut-off point. It probably makes no sense to account for every screw, but it does make sense to account for the numbers of specific types of screws.

There is also the question of naming this concept. The term "property" seems like a bad fit for a system intended for abolishing private property. Some other ideas include:

• dimensions
• use-values
• use-dimensions
• types
• usable-types (Leone Castar uses this terminology)
• product-type (Emmanuel D. Farjoun, Moshé Machover and David Zachariah use this term in How Labor Powers the Global Economy^[4])

Readers are encouraged to bikeshed as much as possible on the naming question.

Propertied accounts

Readers familiar with database normalization might realize it's possible to make the property part of the account name rather than part of the account's value. That is, instead of having one account containing multiple properties, we could instead split each account up into each of the kinds of properties it might hold. The gizmo example from before could then be handled like this:

Account	Debit	Credit
3001 Sales (money)	0	1000
3001 Sales (gizmos)	1	0
2610 Outgoing VAT, 25% (money)	0	250
1930 Company account (money)	1250	0
9001 Inventory (gizmos)	0	1

As far as I can tell this is how foreign currencies are handled in some accounting software, for example GnuCash. The downside of this is that type information is lost. In Ellerman's words, it amounts to adding up "somethings", in this case 1251 of them in both columns. For this reason I believe this approach is wrong. Accounts should instead be "bags" into which we can debit or credit almost any kind of use-value.

Production accounts

Much like Ellerman, I propose production be tracked by suitable accounts. I also propose extending the idea to joint production and to multiple production methods. This idea fetches inspiration from Appendix B.1 of How Labor Powers the Global Economy^[4]. This notion of joint production has been further developed in the Receding Horizon Planning (RHP) project by Zachariah and Hagberg^[7].

Following Kantorovich, let us consider a plywood workshop manufacturing furniture. There may be multiple methods of manufacturing each piece of furniture, and each method will produce different amounts of sawdust and scrap plywood per piece produced.

Let us assume that initially no attempt is made to separate inputs and outputs by production method. From the planning system's point of view the plywood workshop at this stage is a black box, since there is no causal link between inputs and outputs. Any attempt at modelling the workshop must therefore be very simplistic, such as assuming inputs and outputs are constant, or that they vary linearly in fixed proportions with the amount of labour applied. The following illustrates such a model:

$y=\left[\begin{array}{c}\text{Labour}\\ \text{Plywood}\\ \text{Shelves}\\ \text{Tables}\\ \text{Scrap}\\ \text{Sawdust}\end{array}\right]=\left[\begin{array}{c}-1\\ -a_{\text{Plywood}}\\ b_{\text{Shelves}}\\ b_{\text{Tables}}\\ b_{\text{Scrap}}\\ b_{\text{Sawdust}}\end{array}\right]\lambda$

λ is the amount of labour applied, negative signs denote inputs and all a's and b's are positive. The a's and b's are the technical coefficients of the model, A being taken from Leontief's input-output model, and B from Zachariah's joint production model. Even this simple model would be a major step up from the type of modelling possible in historical materialist research today, which is mostly limited to aggregate supply-use tables denoted in money. It is also the kind of model we might derive from companies' yearly reports for open source intelligence or investment planning purposes.

While a step up, the coarse model above is probably not enough. In order to ensure that the workshop is always supplied with the plywood it needs, for different product mixes rather than a fixed mix, the planning system must have a reasonably accurate model of the workshop. Rather than the aggregate technical coefficients presented above, we'd really like to have coefficients describing each production process. Such coefficients can either be given ex-ante from production recipes (bills of materials), or they can be arrived at ex-post via statistics, or both. Accounting is one mechanism by which such statistics can be gathered.

Let's assume that there are two products: shelves and tables. Let's also assume that there are three production methods for these products: one that produces only shelves (method 1), one that produces only tables (method 2) and one that produces both (method 3). When method 1 is used, plywood is credited from "inventory" and debited to "method 1". Labour time is similarly credited from each worker's account and debited to "method 1". It might alternatively be the case that labour is not debited to any specific production method, but to a generic "production" account automatically every day based on the number of workers there that day, to cut down on paperwork. In that case labour could be prorated to each production method's statistics instead, weighted by some suitable measure. This is less accurate that explicit debiting to each production method, but still more accurate than a black box model. When production finishes, shelves are credited from "method 1" and debited to "inventory". When the shelves are picked up for transport in the future, they are credited from "inventory" and debited to some transportation account.

In addition to shelves, method 1 also produces scrap plywood and sawdust. The amount of scrap might be figured out from the production CAM file, as might the amount of sawdust. But for the sake of argument let's assume that the amount of sawdust produced is unknown. In that case the sawdust might instead be weighed at regular intervals and also prorated to the various production methods in the statistics.

A "white box" model of the workplace, with three production methods, might look something like the following:

A linear model might look like the following:

$y=(B-A)\lambda$

subject to

$0\le \lambda \text{and}{\lambda }_1+{\lambda }_2+{\lambda }_3\le 40\text{hours per week}$

within some given time period(s). Again A and B are technical coefficients. How would we arrive at these coefficients? By inspecting the production accounts! Every once in a while the accounts are inspected and A and B derived from them, prorating unexplained inputs and outputs as appropriate. The result might look like the following table:

Method	Inputs		Outputs
	Plywood (sheets, 2500x1200x20 mm)	Labour (hours)	Shelves (pieces)	Tables (pieces)	Scrap (kg)	Sawdust (kg)
Method 1	20	15 ± 2	10	0	3.5	0.75
Method 2	20	16 ± 2	0	10	4.5	0.8
Method 3	10	18 ± 2	5	5	0.5	0.9

The inputs column would correspond to the debits to the associated production account, and outputs to credits. In this example only labour has some level of uncertainty associated with it.

Some readers might object that this is a lot of bean counting, of dubious usefulness. After all, the plywood workshop likely gets rid of about the same amount of sawdust every week, and the person who comes to pick up the sawdust is likely the same person every time. But the system doesn't know this, especially not the people a few steps removed. Without explaining how the sawdust comes about and where it is used and why, the system must rely on ex-post error control. This type of control is known to be inferior to ex-ante model predictive control.

Without a causal link between plywood in, certain production processes and sawdust out, it might seem like sawdust just magically appears in the plywood workshop every week as if falling from the heavens. The fact that an increase in demand for wooden shelves would induce higher demand for wood might be easy enough to anticipate. Less so regarding which specific types of wood (pine and spruce), nor whether enough wood can actually be taken out of the forests while adhering to environmental constraints, especially since the production period for wood is on the order of 100 years. Besides the obvious environmental issue of not anticipating and regulating demand for wood, there is also the problem of sudden gluts and shortages inherent in systems based on error control, such as the market. Even in this specific example, should the demand for plywood products double over some time period, this might result both in a shortage of plywood and a glut of sawdust at the same time.

Finally I will point out that some units do not really engage in "production". This is particularly true of units in the reproductive sphere such as schools and hospitals. But even in this sphere, accurate statistics are useful. If a hospital expands the number of beds, this induces higher demand for nursing labour, for needles and antiseptics, for masks and gloves, for food for the patients that some Iraqi physician eats even though he shouldn't, and so on. In some sense a hospital does engage in production, in that it inputs patients and medical labour power, and outputs healthier patients. While we might not be able to say that the hospital engages in specific production methods, that the labour isn't stereotypical enough for such modelling, it still makes sense to account for the resource use of each of its departments. This way if for example the radiology department is to be expanded, the resulting increased demand for contrast agents can be anticipated.

Future accounting

In business accounting it is common to date some transactions in the future. This is done for things like depreciation of assets, and for invoices that have due dates in the future. Once the invoices are actually paid, the accounts tracking these future invoices are credited at the date the invoices were paid. For example when selling a gizmo to a customer, if sending the invoice on 2024-08-01 with a one month due date, while buying doodads on the same day, might look like this:

Date	Description	Account	Debit	Credit
2024-08-01	Doodads
		1930 Company account	0	125
		2640 Incoming VAT	25	0
		5460 Consumable materials	100	0
2024-09-01	Arreared gizmos to Alice
		3001 Sales within Sweden, 25 % VAT	0	1000
		2610 Outgoing VAT, 25 %	0	250
		1511 Customer arrears	1250	0

The above takes inspiration from how GnuCash displays things, including a blue line to demarcate future transactions.

If on 2024-09-01 the account is checked and the invoice is found to have been payed on 2024-08-29, then we update the ledger to reflect this:

Date	Description	Account	Debit	Credit
2024-08-01	Doodads
		1930 Company account	0	125
		2640 Incoming VAT	25	0
		5460 Consumable materials	100	0
2024-08-29	Gizmo invoice paid
		1511 Customer arrears	0	1250
		1930 Company account	1250	0
2024-09-01	Arreared gizmos to Alice
		3001 Sales within Sweden, 25 % VAT	0	1000
		2610 Outgoing VAT, 25 %	0	250
		1511 Customer arrears	1250	0

Note the lack of a blue line because time has passed.

In an in-kind accounting system, this kind of future accounting can be very powerful. It could be used by workers to signal to everyone that they will want a particular input at some point in the future. That is, it could be used for tentative orders. It could also be used for concrete, legally binding orders, much like how orders work today, except said orders would be public affairs.

The use of tentative orders suggests a connection to the ex-ante planning process. Specifically, future entries in the ledger could be tied explicitly to $\xi$, each workplace's position within the planning polytope. In Quantifying autonomy in planning I don't go into how $\xi$ is actually arrived at, other than suggesting one method of automatically updating it. I now suspect that the in-kind accounting system could be used for this task. The way workers can directly control the planning process should therefore be clear - they control $\xi$, and the planning system can test any change to $\xi$ against the politically and scientifically determined constraints that make up the planning polytope. Any production can be permitted so long as no constraint is violated. There is no need to optimize anything. We can instead view the planning process as an instance of goal programming. This doesn't mean wouldn't do some sort of optimization, only that we don't have to. I plan on writing more on this idea in the future.

Privacy

What I am writing about here are things that would be matters of public record. There is a dividing line between what needs to be known in order to run an in-kind economy, and what does not need to be known. There is potential for doing much better than surveillance capitalism on this front.

For most products and services we only need statistics of how many of each are in demand and where, not who exactly are demanding them. Because the goal isn't profit maximization, we don't need to build a profile of every consumer by spying on them, as capital does now. I will therefore go out on a limb and say that people's medication purchasing habits should not be part of the public accounting system. But how much medication is consumed by each pharmacy would likely need to be.

We should also give some thought to payment privacy, since exchange-value isn't going away any time soon. Here I will simply gesture toward GNU Taler, which has some nice privacy-respecting properties, while still allowing for public accounting of stuff sold.

Another case where privacy is necessary is the war industry - the nuclear weapons industry in particular. From the civilian planning system's point of view the war industry would appear as just one giant black box. To prevent the enemy from gaining insight into it, it could operate on a secret fork of the public ledger, or a set of forks. Such forks would constitute asymmetric access to information in the system, precisely counter to what I've been advocating for here on the blog. Not ideal, but perhaps unavoidable given the nature of the project.

Regardless of whether we officially sanction a secret fork of the ledger or not, the fact is that if we have democratic access to it then nothing in principle prevents personal forks from proliferating. This might even be beneficial for experimenting. We could also imagine that only part of someone's personal fork makes it to the official public ledger, while other parts are kept personal. We might even imagine this happening in a multi-tiered fashion, where for practical reasons only part of the regional forks make it to the global public ledger. I would warn against doing such a thing on principle. This because having maximally disaggregated data is beneficial to planning.

Technical concerns

Storage, synchronization and auditability

One important question on the technical side of in-kind accounting is the question of storage. If we are serious about the democratic part of democratic economic planning, then all public data relevant to planning must be available to all everywhere on the planet, preferably with low delay. The method of storage must be engineered in a way that the system is not easily brought down by disgruntled sysadmins, DDoS attacks, war or disaster. Changes to the data must also be auditable.

In discussing this issue with various people, two methods of storage have popped up:

• a relational database
• files tracked with git

Relational databases are well understood and traditional. There are also auditable databases according to Spyridon Samothrakis. I have no experience with such databases however, only traditional relational databases where changes are not tracked. Changes in such databases are difficult to inspect or revert.

An architecture I can understand would be one based on content-addressable storage, such as git. The ledger could be a set of XML files tracked with git, and changes to the ledger would be done in discrete commits explaining what each change does. This is the way I handle accounting in Umeå Hackerspace at the moment - a GnuCash ledger synchronized with git over ssh. Other data formats and methods of distribution are also possible. For example, we could use a line-based format adhering to a parsing expression grammar (PEG), distributed over IPFS. Or JSON over bzr.

A git-like approach has the benefit that the entire ledger could in principle be downloaded and experimented with offline. Changes to the ledger only require some way of passing files around, and so could conceivably run over sneakernet, in remote areas with mostly store-and-forward internet like the Antarctic, or even across interplanetary distances!

In my own little experiments I find myself converting my data files to an sqlite database to be able to work with them, so perhaps the relational database idea has legs after all. I'm still toying with these ideas.

Size and bandwidth

How large would a global in-kind ledger be, and what would be the bandwidth requirement for synchronizing it? I do not have extensive amounts of data to answer this question with confidence. But what I do have are data from my own company.

I use GnuCash for accounting since 2016. It uses XML as its data format. At time of writing the size of this file is 678331 bytes, 48972 bytes when compressed using xz -9. Exported as a CSV file it occupies 1089 rows. The number of transactions per year breaks down like this over time:

Year	Transactions
2016	13
2017	7
2018	1
2019	21
2020	53
2021	56
2022	50
2023	74
2024	71
Total	346

The average number of rows per transaction is therefore $1089/346\approx 3$, and the size of each transaction after compression is $48972/346\approx 142$ bytes, or 47 bytes per row. My peak accounting rate in 2023 therefore corresponds to 10 KiB/year. Not a lot. But! These numbers are for monetary accounting, not accounting in kind. Some of the transactions above are things like orders from DigiKey, each consisting of hundreds of rows. Most are just a few items however, and thus would just be a few rows. Let's guesstimate the average to be 100 rows per transaction. That would bring the accounting rate per workplace to just under 1 MiB/year, or 60 rows/day.

Is the above reasonable? For small workplaces it probably is. For large workplaces, probably not. But we could split large workplaces up into smaller units such that it does make sense. How many such units could we expect globally? The number of workers worldwide provides a conservative upper bound. According to Our World in Data this number sat at 5.26 billion people in 2023^[5]. Bringing these numbers together we get $74*142*100*5.26*{10}^9/{1024}^5\approx 4.9\text{PiB/year}$, or $74*142*100*5.26*{10}^9/365/24/3600*8\approx 1.4\text{Gbit/s}$. More than manageable with regional datacenters. If we restrict ourselves to the Sraffian basic sector then perhaps the number of units is as low as one million. One million units would only require 270 kbit/s and just under 1 TiB/year, well within the capabilities of consumer hardware.

Pruning

From the above it might seem like the ledger must be an append-only thing, similar to how cryptocurrencies work. But much like with bookkeeping today, the usefulness of in-kind accounting data say 100 years in the past would likely be limited. In some industries, like forestry, we do need such old data since the production period is so long. In other industries, not so much. There is for example little sense in tracking equipment that has long since depreciated and that has been scrapped. In the transportation sector, once a thing has been delivered to its destination, we're only really interested in the statistics of it. Therefore there are grounds to believe the ledger would be pruned from time to time.

Pruning needn't be permanent - it could be undone by using the auditing system, for example git revert if using git. Most places might have a shallow "working copy" of the ledger, ála git clone --depth 1. The full history of the ledger could be kept in permanent storage, on tape.

It might be the case that something has to be permanently removed from the ledger, including its history, for whatever reason. This means violating the auditability property, at least to an extent. It could be done with git's "nuclear option": git-filter-branch. Making such drastic changes would also require a git force-push globally, which still doesn't mean that the data is actually gone everywhere. Such is the price of democratic access.

The pruning itself could be done by summing groups of old transactions into one giant "tail" transaction, and by combining accounts, both of which would tend to shrink the size of the ledger. One could also group old transactions such that repeated orders of say pens end up as just a single row rather than multiple rows spread across multiple order-transactions, which would further shrink the ledger. In the extreme, combining all accounts into one would cause all transactions to go from and to that account, effectively turning them into no-operations. The column sum of every transaction would be zero, so only the metadata of each transaction would remain. If furthermore all transactions are combined into one, then that transaction too would be empty. Therefore all columns could be deleted, and the size of the ledger would shrink to some fixed overhead.

How the above would work with auditable databases rather than git I don't know.

Similar work

There is some similar work to what I've talked about above, such as the people around the From Alpha to Omega podcast, and Leone Castar's work.

With the Alpha to Omega people I primarily mean Tom O'Brien and Donal Ó Coisdealbha, who are very much inspired by the 1930's Group of International Communists. Tom and Donal are currently working on a book called The Classless Society In Motion, wherein they argue for something they call the General Ledger. The General Ledger appears to overlap with some of what I've written above, and undoubtedly there is some crosspollination at work since I listen to their podcast. I have however not heard anything about vector valued accounting from them so far, nor about future accounting. I do think they go a bit into how the ledger could influence an ex-ante planning system, but I don't think I've heard any specifics so far. I would probably butcher the concept if I described it in much more detail. Instead I direct readers to check out the podcast and to also support their book project.

Leone Castar is currently working on a series of texts around what he calls Real Democracy, where what he calls the Library of Industry (LOI) is one component, and the Public Resource Library (PRL) is another, and where in-kind accounting is an important part of both. This has some similarity to the General Ledger, and also what I've called "the wiki of production". Castar also has a concept of a many-to-many map between usable-types and goal-satisfying actions ("use-types"), and some ideas around how usable-types can be subdivided/summarized. Unfortunately none of his texts have been published yet. Hopefully this mention here will serve as motivation!

One way forward

Building an in-kind accounting system seems like a task that is within reach. It would be useful for "test driving" some existing ideas around planning. It would also be useful for open source intelligence, particularly for parsing quarterly reports into a common format and making them available for historical materialist researchers. Based on what I've written above, one path forward could be this:

• Get some users
• Fork GnuCash and add the ability to perform vector-valued accounting in it
• Set up a backend with git+ssh functionality and some basic access control
• Gather feedback from users

Nice-to-haves:

• Integrate git+ssh into the GnuCash fork
• Web frontend

So far I cloned the GnuCash repo, but I had little luck in compiling it. I'm also heading into a rather busy work period soon. After that I should have free time again.

Final remarks

I have heard it claimed more than a few times that socialism/communism would somehow mean the end of accounting, that accounting for things is somehow "bourgeois", or that communism entails such an abundance that we would no longer need to accounting for things, especially labour. I find such notions extremely dubious. Karl Marx points out in chapter 49 of vol III of Capital that:

Secondly, after the abolition of the capitalist mode of production, but still retaining social production, the determination of value continues to prevail in the sense that the regulation of labour-time and the distribution of social labour among the various production groups, ultimately the book-keeping encompassing all this, become more essential than ever.

The climate crisis that stands before us necessitates deeper accounting than what is done at present, not shallower accounting. It needs more sophisticated methods of production, not less sophisticated ones. It needs more coordination, not less coordination. It needs internationalism, not sectioning off the human economy into distinct national or regional economies. Why? Because such sectioning would require introducing regional constraints on emissions and absorptions, rather than a single global atmospheric composition constraint. Such regional constraints would act as a straitjacket on the human economy, preventing exploration of large volumes of the planning space. It would also likely result in a squandering of labour power. Instead, the entire base must be amalgamated into the one single and global system of accounting and control, a single system of regulation that is superior to capitalism, not inferior to it as some self-flagellants would have it.

Whether what I've said above must encompass all production I don't know. Perhaps it doesn't have to. Perhaps it can't. For example, perhaps it is not necessary for the system as a whole to know what your local hairdresser is doing. What is certain is that it must encompass large parts of those sectors whose impact on the environment are the greatest: energy, transport, heavy industry, food, forestry and so on. Failure to do so will bring immense misery.

Statistics

I began writing this post on 2024-05-19. This not only makes it the post that has taken the longest to write, but also the largest post so far. The markdown file that makes it up weighs in at 50 kB.

References

[1] Ellerman, David. 1985. The Mathematics of Double Entry Bookkeeping. Mathematics Magazine. 58 (September): 226-33.

[2] Ellerman, David. 1986. Double Entry Multidimensional Accounting. Omega, International Journal of Management Science 14, no. 1: 13-22. ellerman.org (fetched 2024-07-08)

[3] Ellerman, David (December 5, 2007). "Double-Entry Accounting: The Mathematical Formulation and Generalization". SSRN Electronic Journal. doi:10.2139/ssrn.1340619, SSRN (fetched 2024-06-13), Researchgate (fetched 2024-06-13)

[4] E. D. Farjoun, M. Machover and D. Zachariah, How Labor Powers the Global Economy: A Labor Theory of Capitalism, Springer Cham, 2022, doi:10.1007/978-3-030-93321-0.

[5] Population of young, working-age and elderly - Our World in Data. https://ourworldindata.org/grapher/population-young-working-elderly-with-projections (fetched 2024-08-14)

[6] Pacioli, L. 1914 (orig. 1494). Summa de Arithmetica, Geometrica, Proporcioni et Propocionalita. Trans. J. B. Geijsbeck. In: Geijsbeck, J. 1914. Ancient Double-Entry Bookkeeping. Houston: Scholars Book Company.

[7] Zachariah, Dave and Hagberg, Loke. 2023. Receding Horizon Planning for Economic Coordination. https://github.com/lokehagberg/rhp (fetched 2024-07-19)