Federated Bookkeeping is the technique of electronically linking two or more bookkeeping systems, in such a way that accounts, purchase orders, invoices, tax statements, etc. stay in sync without the need to go through the traditional export and send process at one system, followed by the receive and import process at the other system.
One approach to federated bookkeeping is world ledger gossip: nodes in the network gossip with each other about transactions that happen between parties, and that together make up the world ledger. Each node has only a partial view of the world ledger, so unlike in blockchain systems, no complete consensus is reached (see also how gossip is used in for instance HoloChain and ScuttleButt).
The events this gossip reports on would have to be modeled in such a way that they can be meaningfully compared and interrelated, so although it's always hard to pick a model and not end up bikeshedding about it, a transaction on the world ledger would probably have the mandatory fields "id", "from", "to", "date", by which transactions can be uniquely identified, located, and partially ordered on the world ledger. When gossiping about a transaction between accounts at different network nodes, there will often be two representations of it: one at the sending node and one at the receiving node.
Sometimes these are called two transactions (one on each account statement) that together represent a transfer. In this context we don't model the account statement entries as objects in their own right; instead, they are both a form of gossip about one single event (one transaction from Alice to Bob, or equivalently, one transfer from Alice to Bob).
A multi-hop chain of transactions (hops, transfers) is sometimes called a single transaction; for instance Interledger assumes all transactions are multi-hop chains of local ledger transactions which themselves are called (single hop) transfers, to distinguish them from (multi-hop) transactions. But since in current-day accounting multi-hop is still an exception, on this website, we'll use the word "transaction" to indicate a single hop, and use a word like "chain", "loop" or "cycle" to indicate when these transaction are linked into a multi-hop or circular group.
Without a global view of the ledger it would be impossible to calculate a global balance, but using optional fields "amount / unit" and "state" (confirmed, proposed, declined, etcetera) would allow the calculation of a local payable / receivable / current balance, like in SNAP. With fields like "description" or "data", transactions could be linked to off-ledger events, and transactions could also link to each other on-ledger to establish a complete ordering of accepted transactions, and/or to indicate when two hop transactions form part of the same multi-hop chain or cycle.
Apart from transactions, a bookeeping system would generally also model Purchase Orders, Invoices, Cost Centers, Loans, Mortgages, Shipments, Stock, etcetera. If a supplier and a customer both have a bookkeeping system (most companies and even many individuals do have a bookkeeping system of some sort), then they can federate their bookkeeping systems ('connect their books') to make changes in one system immediately show up in the other system, thereby greatly reducing the friction and miscommunication in everyday trade.
Since Federated Bookkeeping is not in itself a digital asset, participation in the world-wide bookkeeping network does not require a Money Transfer Agent license.
Solid's MoneyPane is a first implementation of a simplistic bookkeeping system that supports Federated Bookkeeping. It is still under construction. The design consists of several components:
See the Network Money mailing list for a discussion forum around the topic of Federated Bookkeeping.
See the GitHub repo for this website if you want to propose changes to the HTML content of this website.