8 posts tagged with "accounting"

A fee schedule is a business policy, not just a percentage. The same amount may attract different charges at an ATM, at a contactless terminal, or online. A merchant category may carry a surcharge. Small transactions may need a floor, large ones a ceiling. Several independently disclosed charges may apply together.

Hard-coding each variation turns pricing changes into software releases. Making everything freely editable creates a different problem: one configuration change can affect every transaction on a product. jCard brings these concerns together—expressive pricing rules, a controlled approval lifecycle, and evidence of what was actually charged.

The first Counterpart demonstration used Bitcoin because it makes the cost of two copies impossible to ignore. A transaction on a public network and a ledger entry inside an institution are plainly different things. Somebody has to connect them, explain the confidence of that connection, and deal honestly with reversals.

This video starts closer to home: two entities on the same Control Plane. ACME Services raises an invoice. Beta Retail sees it as a proposed payable and accepts it. Both sides settle the same advice.

Every payment system eventually builds a reconciliation operation.

It may be a small team with a spreadsheet, a nightly job that matches files, or an entire department armed with exception queues and carefully named CSV exports. The tooling varies; the underlying problem does not. A single economic event is captured independently by several systems, and somebody must later decide whether their records describe the same thing.

That is an expensive way to learn the truth.

A merchant has an order. A processor has an authorization. An acquirer has a clearing record. A bank has a movement. A wallet has an on-chain transfer. Each record is useful, each is locally correct, and none is automatically the other. Reconciliation is the work required to turn those separate claims into one operational fact.

The usual answer is more matching: stronger references, better files, more frequent imports, smarter exception handling. Those are worthwhile improvements, but they optimize the aftermath. They do not change the fact that the system started with multiple copies.

Counterpart begins somewhere else: make the relationship between a ledger entry and the thing outside the ledger explicit from the beginning.

Every ledger has a set of transactions it posts over and over. The accounts change, the amounts change, sometimes the counterparty changes—but the structure is always the same. A fee charge is always a debit to the customer account and a credit to fee income. A settlement is always the same four entries. A foreign exchange conversion follows the same arithmetic every time.

Freeform posting can handle all of these, but it puts the entire burden of correctness on the operator: right accounts, right sides, right layer, right formula—every time, by hand. Templates solve this. A template captures the invariant structure of a transaction and exposes only the parts that actually vary. Everything else is handled by the ledger.

Most ledger enforcement is hardcoded. If the business needs a new limit—a maximum account balance, a cap on transaction size, a rule that blocks weekend postings—someone files a ticket, a developer writes a check, the code ships in the next release. That cycle takes days or weeks, and the logic lives in application code rather than in the ledger where it belongs.

MGL solves this with Dynamic Rules. A dynamic rule is a CEL expression that the system evaluates on every posting, in real time, before the transaction is committed. If the expression returns false, the transaction is denied. No code change required. No deployment.

Most accounting systems that want to show derived figures—variance against budget, percentage execution, a consolidated multi-currency total—end up solving the problem the same way: periodic batch jobs that write synthetic entries to hold the computed values, or reporting scripts that reconstruct the computation at query time outside the ledger.

Both approaches have the same flaw. The derived figures live in a different place than the authoritative entries. They get stale. They diverge. Reconciling them back to source is always someone's problem.

MGL solves this with virtual layers. A virtual layer carries a formula instead of entries. Its balance is computed on the fly from physical layers—always derived from the same source of truth, always accurate to the query date, with no batch job required.

One of the things that breaks down quickly in real-world accounting systems is currency.

Most ledger designs treat currency as an afterthought — a field on a transaction, a conversion applied at reporting time, a problem deferred to the spreadsheet team. MGL treats it differently. Exchange rates are a first-class part of the data model, imported automatically, stored with full history, and wired directly into the layer architecture so that multi-currency consolidation happens at query time, not at batch time.

MGL is starting to feel like a real system now, not just a collection of ideas.

The core ledger is already in place, but what makes it interesting is how the pieces are starting to come together: multi-layer accounting, virtual layers for reporting and FX-driven consolidation, high-volume controller-style account structures, and an AI assistant that can operate the system through the same tools and permission model used by the web UI.