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.
World Ledger Gossip
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
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.