What is a real-time general ledger, and why does it matter for commodity traders?

By Saurabh Goyal, Founder & CEO of Phlo Systems. Published 2 August 2026.

Ask a commodity trading CFO how current their P&L is and most will say "as of last night's batch," some will say "as of last week," and a few, honestly, will say "we're not sure until month end." The general ledger is supposed to be the single source of truth for the business. In most trading firms it is instead the slowest source of truth — a nightly or monthly reconciliation of what the trading book, the warehouse, and the bank already knew hours or days earlier.

The 30-second answer: a real-time general ledger posts the accounting entry for a transaction — a trade, a receipt, an invoice, a mark-to-market revaluation — in the same transaction that creates it, not in an overnight batch job. The GL is never behind the business; it is the business, from an accounting point of view, at every moment. That sounds like a technicality. In practice it is the difference between a CFO who can price a decision today and one who finds out what today cost three weeks from now.

The difference between a subledger-driven and GL-driven trading system

Most CTRMs are subledger-driven. The trading book — positions, MTM, physical deals, hedges — lives in the CTRM's own data model. A separate process (nightly batch, weekly export, sometimes a consultant's spreadsheet) translates trading activity into journal entries and posts them to the GL, which lives in a different system (Sage, Xero, QuickBooks, Dynamics, sometimes SAP). The GL is a subledger consumer: it receives a summary of what happened, after the fact, in a format the accounting system was built to accept.

A GL-driven system inverts this. The trading book and the general ledger share one data model. Booking a physical purchase does not "eventually feed" the GL — it is a GL posting, made of a debit and a credit, at the moment the trade is booked. There is no translation step, because there was never a second representation to translate from. The trading book and the GL are the same fact, viewed two ways.

The practical test is simple: ask your current vendor what happens, technically, between "trader clicks confirm" and "GL account balance changes." If the honest answer involves a batch job, a nightly sync, an export/import step, or a reconciliation report, you have a subledger-driven system, however good its trading functionality is.

Why legacy CTRMs bolt accounting on as an afterthought

This is not an oversight — it is architectural history. ION, Triple Point, Openlink and their peers were built by trading technologists to solve position management, risk, and MTM for large trading houses that already had a general ledger (usually SAP or Oracle) and a finance team dedicated to reconciling the two. The CTRM's job was never to be the accounting system; it was to be good enough at trading to justify the integration cost of bolting it onto whatever GL the finance team already ran.

That division of labour makes sense at a £10B trading house with a dedicated integration team. It breaks down at SME and mid-market scale, where the same 15-person finance team is expected to run treasury, close the books, and reconcile CTRM output against Sage or Xero by hand — see why SME commodity traders deserve an integrated ERP + CTRM + Treasury system for the fuller argument. The GL-as-afterthought design was rational for the customer it was built for. It was never rational for the customer who now has to buy it because there is no alternative.

Mark-to-market, unrealised P&L, and the GL: getting it right daily

The hardest accounting problem in commodity trading is not booking a completed trade — it is booking the unrealised position. Every open position has a mark-to-market value that moves with the forward curve or the spot price, and that unrealised P&L has to hit the GL as an accrual, reverse cleanly the next day, and re-post at the new mark, without ever double-counting or leaving a stale balance sitting in an account nobody is watching.

In a subledger-driven system, this reversal-and-repost cycle is exactly the kind of batch job that breaks quietly: a valuation date that doesn't match the accounting date, a reversal that runs before the new mark is ready, a position that closed out during the day and gets marked and realised in the same nightly run. Because the process runs unattended overnight, these breaks are usually found at month end, by which point they have compounded for weeks.

In a GL-driven system, the MTM revaluation is a GL posting the moment the price feed updates and the valuation runs — same data model, same transaction, no reversal job required because there was never a stale prior-day accrual sitting separately from the position that created it. Daily unrealised P&L is not a batch output to be trusted after the fact; it is a live account balance a CFO can query at 10am and trust.

Continuous close vs monthly close for commodity traders

The most visible symptom of a subledger-driven GL is how long month-end close takes. A typical mid-market commodity trader running CTRM-plus-accounting-package closes books 15–25 days after month end, because two weeks of that window is spent reconciling what the CTRM says happened against what actually posted to the GL, then explaining the variances.

A real-time GL removes the reconciliation because there is nothing to reconcile — every transaction posted once, correctly, when it happened. Firms running on this architecture typically close in 2–5 days; "close" becomes a reporting cutoff and a review, not a two-week forensic exercise. The difference compounds: a CFO who closes in 3 days has a current P&L for decision-making roughly 20 days more often per year than one who closes in 23.

	Subledger-driven (batch)	Real-time GL
When does a trade hit the GL?	Overnight batch or nightly export	Same transaction as the trade
MTM revaluation	Reversal + repost job, run unattended	Live posting on price update
Typical month-end close	15–25 days	2–5 days
Where reconciliation breaks show up	Month end, after compounding	Same day, before compounding
Who finds the error	Auditor or CFO, weeks later	The system, immediately

What "real-time GL" enables: margin calls, credit decisions, position sizing

A current GL is not an accounting nicety — it changes what decisions a trading desk can make with confidence, same day:

• Margin calls. If unrealised P&L on a hedge book is a live GL balance rather than a nightly estimate, treasury knows the actual cash exposure before the exchange calls for variation margin, not after.
• Credit decisions. Extending a buyer's credit limit against a current, not month-old, view of exposure and cash position is the difference between a considered decision and a guess with a fig-leaf of process around it.
• Position sizing. A trader deciding whether to add to a position needs today's realised and unrealised P&L, not last week's, to know how much risk budget is actually left.

None of these require a smarter trader or a better risk model. They require the accounting to be current, because every one of these decisions is, underneath, a question about money the business actually has right now.

Questions to ask any ERP or CTRM vendor about their accounting core

Five questions that separate a real-time GL from a well-marketed batch process:

1. "Show me a trade being booked and the GL balance changing, live, in the same screen." If the demo requires switching to a different system or running a sync, it is not real-time.
2. "What happens to an open position's MTM accrual overnight?" If the honest answer involves a reversal job, ask what happens when that job fails silently — because it does, eventually.
3. "How long does your median customer take to close month end?" Ask for a number, not an adjective. "Fast" is not a number.
4. "Can I get a trial balance as of right now, mid-month, without running a special report?" In a real-time GL this is a standard query. In a subledger system it usually isn't, because the GL is only current as of the last batch.
5. "If I export every GL transaction to a spreadsheet, can I reconcile it to your trading book without a separate reconciliation report?" If the vendor needs a dedicated reconciliation tool to prove the two systems agree, they are two systems.

Frequently Asked Questions

What is a real-time general ledger?

A general ledger that posts the accounting entry for a transaction — a trade, a receipt, an invoice, a revaluation — at the moment the transaction happens, using the same data model as the system that created it, rather than receiving a batch summary on a delay. The GL balance is always current, not current-as-of-last-night.

Why do most CTRM systems post to the GL overnight instead of in real time?

Because most CTRMs were built as subledgers designed to feed a separate accounting system the finance team already used (SAP, Oracle, Sage, Xero). Translating trading activity into GL-ready journal entries and posting them was architected as a batch integration step, since the two systems were never meant to share one data model.

How does a real-time GL change month-end close?

It removes the reconciliation step that consumes most of a traditional close, because every transaction posted once, correctly, when it happened rather than being reconciled after the fact. Firms on real-time GL architecture typically close in 2–5 days versus 15–25 days for a fragmented CTRM-plus-accounting-package stack.

Does a real-time GL replace the need for a month-end close entirely?

No — a close is still a reporting cutoff, a review, and statutory sign-off. What changes is what the close consists of: a review of already-correct numbers rather than a forensic reconciliation exercise to discover what the correct numbers are.

Is "real-time accounting" just marketing language, or is there a way to verify it?

It's verifiable. Ask the vendor to book a trade live in a demo and show the GL trial balance changing in the same screen, without a sync step. Ask what their median customer's month-end close takes, as a number. A vendor with a genuinely real-time GL will answer both without hesitation.

How Phlo Systems helps

opsPhlo is built with a real-time general ledger as its accounting core, not as a downstream integration. Every trade booking, inventory movement, invoice, and MTM revaluation posts to the GL in the same transaction that creates it — there is no nightly batch, no reversal job, and no separate reconciliation report, because the trading book and the GL are the same data. Customers running opsPhlo typically close month end in days rather than weeks, and can pull a trial balance mid-month without asking for a special report. See how opsPhlo's real-time GL works.

---

Related reading:

• Why SME commodity traders deserve an integrated ERP + CTRM + Treasury system
• What is the difference between Commodity Management (CM) and CTRM?
• The 2026 CTRM Buyer's Guide: How to Evaluate Commodity Trading Software Without Regretting the Decision Three Years Later

Saurabh Goyal is the Founder & CEO of Phlo Systems. He spent 12 years building CTRM and ERP systems for global commodity trading houses before founding Phlo in 2016.