Period Entry Methodology & Blockchain Infrastructure for Real-Time Financial Intelligence
This paper proposes a fundamental redesign of accounting infrastructure that eliminates reconciliation, enables real-time financial visibility, and transforms payments into email-like speed and ease of transacting. By combining blockchain technology with a novel "Period Entry" methodology, it creates a shared economic reality where all parties see the same transactions simultaneously—an "Internet of Accounting" that does for financial flows what the internet did for information flows.
The technology exists. The accounting logic is simple. The economic benefits are overwhelming. What remains is adoption.
Modern accounting suffers from three critical flaws:
Period Entry Accounting tracks transactions over temporal intervals rather than at arbitrary points in time. Each transaction has an economic lifespan; the system calculates crossover periods to generate profit/loss, balance sheets, and cash reports continuously—daily, weekly, or monthly—without requiring a general ledger or periodic adjustments.
Blockchain infrastructure provides the shared, immutable transaction log where all authorized parties see the same data simultaneously. Combined with Period Entry tracking, this eliminates reconciliation entirely: there's only one ledger, one source of truth, visible to all participants in real-time.
Profit & Loss reports are captured at periodic moments—for example, the month of December. This creates artificial temporal boundaries. Companies spend enormous effort "closing the books"—reconciling accounts, chasing variances, ensuring everything balances at that precise moment.
Double Entry calculates invoice values and relative accounting adjustments to those values as points in time. So an invoice for the purchase of stationery on 12th December falls into the fixed accounting period of December 2025. But a one year insurance contract that is invoiced on 20th December must be adjusted via journals, one for each month. So the entries in the system are 13 journals: First to move the invoice value into prepayments and then one each month for the rest of the year.
The heart of accounting—the accruals process: depreciation, prepayments, deferrals and accrued revenue—is an add-on to the invoice processing system. This add-on is the general ledger. The adjustments require detailed reconciliation verified via audit. It is open to error and fraud and creates a mystique of complexity around accountancy, making financial processes an impenetrable wall in organizations.
Period: 20th December 2025 to 19th December 2026
Value: £1,200
Reporting Period: 1st June to 30th June 2026
The crossovers are:
Result: There is no need for a general ledger. There is no reconciliation and no audit of the bookkeeping needed.
Currently each company maintains separate books:
Same transaction, recorded twice, in separate ledgers. Now you must reconcile: Did they receive the invoice? Do their records match yours? Has payment been made? Do payment records match?
And again recorded separately on the customer's bank and again separately on the supplier's bank.
Multiply this by thousands of transactions, hundreds of counterparties, continuous activity. Companies spend enormous resources reconciling ledgers, chasing variances, managing timing differences.
Parties: Customer, Customer Bank, Supplier, Supplier's Bank
Single transaction on shared ledger:
Result: No reconciliation needed. One truth. Real-time visibility.
Double entry is backwards looking. The forecast is an add-on, normally in a spreadsheet. Huge effort is required to project this forward. This is both aggregate and point-in-time based. Forecasting systems duplicate the data already held in the transaction processing systems.
Period Entry turns this around in two ways:
Current payment systems are held back by settlement delays, intermediary verification, clearing houses.
Your company pays the supplier on their banking app. The supplier receives the payment on their banking app, banks clear funds. Both parties reconcile records. Days or weeks. Multiple intermediaries. Constant reconciliation. This means that FX gains and losses are incurred.
Currently, each company tracks only its own Period Entries. They cannot see upstream or downstream—other customer's or supplier's transactions.
The manufacturer doesn't know the retailer's inventory levels. The retailer doesn't know the manufacturer's production schedules. Each optimizes locally, system suboptimal globally.
Each has a partial view. Cannot optimize the chain as a whole.
The system optimizes as a whole.
Result: Dramatically reduced waste (inventory, overproduction, stockouts), faster response to demand changes, better coordination without central planning.
The blockchain contains historic transactions up to the present moment. But this data is more than history—it contains the drivers and relationships that define how the business actually works. The historic data isn't just a record. It's a model of the business itself.
Traditional approaches treat data and models as separate things: you extract data, then build a model to forecast from it. But in the Internet of Accounting:
This is exactly how brains work: memories aren't stored separately from the "model"—the memories ARE the model. The weights ARE the knowledge. The same principle applies here: the ledger IS the business model.
The blockchain is naturally a graph:
Graph Neural Networks (GNNs) are designed exactly for this structure. They learn patterns from the relationships, not just the data points.
This is strengthened further with federated learning (each party trains locally, shares only model weights), differential privacy (noise added so individual transactions can't be reverse-engineered), and homomorphic encryption (compute on encrypted data without decrypting).
The system learns continuously as new transactions arrive:
New transaction arrives
→ Becomes history
→ Updates the graph
→ GNN reweights
→ Forecasts update
→ Expectations adjust
→ Next actual vs expectation = prediction error
→ Learning continues
This is ECF (Emotional Comparator Framework) applied to accounting:
The whole system learns from prediction errors. No separate "planning model" maintained in a spreadsheet. The ledger and the forecast are ONE THING.
The GNN learns: "When entity A's Period Entries look like X, entity B's typically follow with Y, at lag Z." Forecasting emerges from the graph structure itself.
Accurate and transparent financial data transform the world.
With shared ledgers, calculate aggregate economic prediction errors across markets and countries.
Central banks currently rely on lagging indicators: GDP (reported quarterly, 1-2 months delayed), unemployment (monthly), inflation (monthly). Policy made with stale data.
Monitor aggregate variance between expected and actual:
Instead of waiting for quarterly GDP reports showing the economy already in recession, detect rising negative prediction errors in real-time and respond immediately.
Blockchain enables selective disclosure. Participants see only authorized transactions. Regulators see aggregates without individual details. Not everything public, but no private inconsistencies—your ledger matches my ledger by construction.
The first question from every accountant, auditor, and CFO: "Does this comply with IFRS and GAAP?"
The short answer: Yes. More naturally and far more easily than traditional accounting.
Period Entry doesn't just achieve compliance—it embodies the core principles that accounting standards are trying to enforce. While traditional accounting achieves those principles through elaborate corrections (adjusting entries, accruals, deferrals), Period Entry achieves them by design.
IFRS doesn't mandate double-entry bookkeeping. It doesn't require general ledgers. It doesn't specify that you must use debits and credits. It specifies economic principles. Any system that achieves those principles complies with IFRS. Period Entry achieves them more directly.
Over the last twenty years revenue recognition in IFRS and US GAAP has been transformed. Perhaps the most complex example is revenue recognition of mobile service payments.
You sign a £300 phone contract. You are contracted to pay £25 per month for 12 months. You receive a handset worth £180 at the start of the contract. But the handset is delivered on day one so the revenue of the handset is incurred on day 1. There is a horrible mismatch.
A Period Entry which has the 12 monthly payments made at the end of each month totalling £300 and two revenue periods:
Once the Period Entry is set up, all the monthly adjustments are calculated automatically. There is no closing period. Reporting is real time, any period, one day, one week, one month. The contract is also perfectly forecast into the future. There is no need for a separate cash forecast.
The Internet of Accounting represents a structural shift in how economic activity is recorded, shared, analysed, and acted upon. By replacing point-in-time double-entry adjustments with Period Entry Accounting, financial statements become real-time outputs of economic lifespans rather than the by-product of a reconciliation process. By placing these Period Entries onto shared blockchain infrastructure, reconciliation itself disappears—replaced by a single, common economic reality visible to all authorised parties.
The implications are profound: payments settle instantly; financial reporting becomes continuous; forecasting emerges naturally from the end dates of transactions; and entire value chains can coordinate through transparent, real-time prediction error signals. What once required general ledgers, adjusting journals, clearing houses, and siloed systems becomes a unified flow of economic information operating with the speed and simplicity of email.
The technology exists. The accounting logic is simple. The economic benefits are overwhelming.
The Internet of Accounting is not merely an improvement—it is the natural next stage in the evolution of economic systems.
Earliest End = the earlier of transaction end date and report end date Latest Start = the later of transaction start and report start Crossover days current = earliest end - latest start Crossover portion current only = crossover days current / length of period in days Current Income/Expense = crossover portion × transaction value
Earliest End = the earlier of transaction end date and report end date Earliest Start = the earlier of transaction start date and report end date Crossover days All = earliest end - earliest start Crossover portion current + prior period = crossover days All / length of period in days Total Income/Expense = (Crossover portion current + prior period) × transaction value Prior period income/expense = Total Income/Expense - Current Income/Expense
Where payment date <= Report end date, payment was made Income/Expense - receipt/payment made to date = accrual