Skip to main content

MassiveGL Is Taking Shape

· 5 min read
Alejandro Revilla
Alejandro Revilla
jPOS project founder

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.

The short demo above starts from a blank system and goes through the basic flow:

  • create an entity
  • create a journal
  • select a standard chart
  • define a layer for USD
  • ask the AI assistant to generate a usable chart of accounts
  • ask the AI assistant to prepare a draft opening balance transaction
  • review, post, and reverse transactions

That flow matters because it shows the direction of the project. MGL is not starting from scratch. It is based on miniGL, a previous generation that, despite the "mini" name, has been used in production as the system of record for very large jCard deployments, including at least two known cases with more than 1.5 billion cards on file.

So the point of MGL is not to prove that a ledger can exist. That part was settled a long time ago. The point is to address the pain points observed in those very large systems, while pushing the model forward with better layering, better operational tooling, and better integration points, including AI-assisted workflows.

Virtual layers​

One of the most interesting features is the virtual layer support.

Physical layers let us post independent values inside the same journal, typically by currency or reporting dimension. But virtual layers are where things get really interesting: instead of storing entries, they compute balances on demand from formulas.

That gives us a very clean way to build consolidated reporting views. You can keep native postings in their original layers and then define a virtual layer that combines them, applies FX rates, or derives reporting values without polluting the base ledger with synthetic entries.

This keeps the original postings intact while still making it possible to answer questions such as:

  • what is the balance of this account in a reporting currency
  • what does a consolidated view look like across several operating layers
  • how did that view look on a specific historical date

That's an important distinction. This is not just a matter of attaching currencies to entries; layers are treated as a first-class accounting dimension, and virtual layers make it possible to compute on top of that model.

Controlled accounts at scale​

Another important piece is support for controlled accounts, implemented in the engine through controller-style account structures.

Traditional chart hierarchies are fine for ordinary financial statements, but they start to hurt when you need to group very large numbers of subsidiary accounts. Customer wallets, merchant positions, vendor balances, or other high-cardinality structures need something more scalable than a tree that eagerly loads children.

MGL's controller-oriented model is meant for exactly that scenario. The parent can represent the controlled aggregate, while the underlying final accounts can grow into the thousands or millions without turning balance queries into a disaster. That opens the door to using the same ledger engine both for classical accounting and for much more operational, high-volume sub-ledger work.

This is one of the areas where the project starts to separate itself from simpler GL implementations.

AI that actually does useful work​

The AI integration is also becoming much more concrete.

The demo is not using AI as a decorative chatbot. It is using the assistant to do useful ledger work:

  • generate a chart of accounts
  • create bank accounts in the right place
  • draft a balanced opening transaction
  • populate the posting console for human review

What matters here is not the chat UI itself, but the execution model behind it. The assistant uses the same backend tools and respects the same authorization model as the rest of the application. That means the AI is not a side channel; it is another client of the platform, with the same need for permissions, validation, and auditability.

This is the only way AI belongs in systems like this. It has to help operators move faster without bypassing the controls that make the ledger trustworthy in the first place.

More shape, less hand waving​

There is still a lot to do, of course, but the project already has a recognizable center of gravity:

  • a real double-entry engine
  • journals with explicit layers
  • virtual layers for reporting and FX conversions
  • controller-style support for large controlled account populations
  • transaction templates
  • reversals and transaction groups
  • AI-assisted setup and posting

That is enough to start seeing where MGL wants to go.

The old miniGL idea was always useful, but this is starting to feel like something much broader. MassiveGL is a better name for the current ambition.

More demos and documentation will follow as the model continues to settle down.