Definition

Federated Bookkeeping is the vision of connecting existing bookkeeping systems together. It uses peer-to-peer messages to connect economic agents, independent of any central authority.

In that sense, it basically builds credit networks on top of e-invoicing.

The bookkeeping messages replace the communication function of payments / currencies / money, but payments are still used to allow trade with strangers. Payments are taken out of the critical path of day-to-day business, but their role as an insurance is retained.

Bookkeeping messages are potentially much more efficient, expressive, and powerful than the price signals carried in payments. They allow coordination of trade, cooperation, trust, credit, production triggers, and footprint reduction.

Advantages

A common (status quo) situation for a business organisation or a human being is to use a mix between human memory and regular (non-federated) bookkeeping to keep track of value flows, and then to use monetary payments to settle these flows. Federated bookkeeping has several advantages over this.

Automation

In the short term, organisations and individuals who adopt federated bookkeeping (for instance, e-invoicing, federated timesheets) can get paid faster, reduce errors, and reduce effort / personnel costs. The federation protocols take over tedious work from communication flows that would currently involve human work and manual data entry.

Linked books will also offer the ability to communicate more relevant information like liquidity or fluctuations in output in real-time, depending on the demand and proximity of both parties.

Conscious Business

In the medium term, having more real-time data about the source and after-sales of your business will make you more conscious of the footprint of your actions. This will hopefully lead to more informed, conscious and harmonious decisions around the social and environmental impact of business activities.

Mutual credit

Shareholders generally want return on investment without too much consideration of what economists call "externalities". In the long term, more transparency can lead to more trust in the supply chain, and more use of supplier credit (e.g. "pay this invoice in 90 days from now"). More mutual credit means less financial loans and less shareholder primacy, meaning the team working on a project has more freedom to take conscious business decisions without referring to monetary profit as the ultimate goal of any activity. Federated Bookkeeping can therefore be a tool that helps the Degrowth transition.

Also, as adoption of federated bookkeeping increases more and more, credit and debit can cancel each other out through third parties. When such an in-network settlement happens (maybe using LedgerLoops or Interledger Full Circle, the need for an out-of-band settlement of credit lines can be postponed, and our dependency on anonymous currencies and the plain-old-banking-system can be decreased.

Decentralisation of Power

Centralised power can lead to monopolies and rent extraction. Federated data architectures (Personal Data Stores, Personal Cloud Servers, Federated Social Web, Local First, Federated Bookkeeping) are therefore preferable over centralised data architectures. Even community currencies are generally administered by single-instance computer systems and could (as Ryan Fugger already proposed long ago) be replaced with federated (multi-instance) computer systems.

Guest Lecture at CERN about Federated Bookkeeping

Community Channels

Projects

Local credit networks

Technology projects

Payee Identity

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

Implementations

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:

Discussion

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.

See the blog page or our medium account for blog-posts about federated bookkeeping.