1. The Problem: Point-in-Time Accounting
Double-entry bookkeeping records invoice values at points in time. An invoice for stationery on 12th December falls into the accounting period of December 2025. No adjustment needed — the economic event and the payment coincide.
But a one-year insurance contract invoiced on 20th December cannot simply be recorded as a December expense. The economic benefit spans twelve months. So the accountant creates adjusting journals: one to move the invoice value into prepayments, then one each month for twelve months to release the cost. Thirteen entries for one transaction.
This pattern — record the invoice, then correct it — is the foundation of modern accounting. Depreciation, prepayments, accruals, deferred income, deferred revenue: all are corrections applied after the fact to reconcile point-in-time records with temporal economic reality.
The closing process — "closing the books" — exists entirely because the system does not natively understand time. Month-end becomes a frantic exercise in ensuring that every temporal adjustment has been correctly applied to every transaction whose economic life crosses a period boundary. The effort is enormous. The scope for error is vast. And the output is a snapshot of a single arbitrary moment rather than a continuous picture of economic reality.
2. The Solution: Period Entry
Period Entry replaces the invoice with a transaction that has an economic lifespan. Instead of a value at a point in time, there is a value over a period of time.
2.1 The Primitive
A Period Entry consists of:
| Component | Definition |
|---|---|
| Value | The total economic value of the transaction |
| Start date | When the economic benefit begins |
| End date | When the economic benefit ends |
| Payments | One or more cash movements, each with a date and amount |
That is the entire data model. Everything else — P&L, balance sheet, cash flow, accruals, prepayments, deferrals — is derived by computation.
2.2 The Core Computation
Given any reporting period, three values are calculated:
The accrual is not an adjustment. It is not a journal entry. It is not a correction applied after the fact. It is the natural arithmetic consequence of recording time.
2.3 Example: Insurance Contract
An insurance contract runs from 20th December 2025 to 19th December 2026. Value: £1,200. Payment: £1,200 on 20th December 2025. Reporting period: 1st June to 30th June 2026.
Transaction life: 20 Dec 2025 → 19 Dec 2026 (365 days)
Report period: 1 Jun 2026 → 30 Jun 2026
Current period cost = 30 / 365 × £1,200 = £98.63
Prior period cost = 163 / 365 × £1,200 = £535.89 (20 Dec to 31 May)
Cumulative cost = £535.89 + £98.63 = £634.52
Payment made: £1,200 (paid 20 Dec, before report end)
Accrual = £634.52 − £1,200.00 = −£565.48
(Negative: cash paid exceeds work done → prepayment asset of £565.48)No general ledger. No adjusting journal. No prepayment account to maintain. The prepayment is calculated on the fly for any reporting period.
2.4 No Month-End Close
Because the computation works for any reporting period — one day, one week, one quarter, any arbitrary date range — there is no concept of "closing the books." The financial position at any moment is derived directly from the transaction data. Real-time reporting is not an aspiration. It is the default.
2.5 Built-In Forecasting
Double-entry is backward-looking. The forecast is a separate exercise, typically maintained in spreadsheets, duplicating data already held in the transaction processing system.
Period Entry has a natural forward view. The end date of each transaction is visible. Uncommitted future periods can be projected from the current transaction's economic lifespan. There is no need for a separate financial planning and analysis tool. The forecast is embedded in the transaction itself.
3. Accounting Standards Compliance
The first question from every accountant, auditor, and CFO: does this comply with IFRS and GAAP?
IFRS does not mandate double-entry bookkeeping. It does not require general ledgers. It does not specify debits and credits. It specifies economic principles: revenue recognised when earned, expenses matched to periods they benefit, assets and liabilities measured at appropriate values, financial statements that fairly represent economic reality. Any system that achieves these principles complies with IFRS.
Period Entry does not merely achieve compliance. It embodies the principles that accounting standards are trying to enforce. Where traditional accounting achieves these principles through elaborate corrections, Period Entry achieves them by design.
4. Proof of Concept: Rent-Free Periods
A tenant signs a 24-month lease at £1,000 per month with a 3-month rent-free period at the start. Under IAS 17 / IFRS 16, the total cost must be spread evenly across the entire lease term, not recognised only when cash is paid.
4.1 Period Entry Setup
| Component | Value |
|---|---|
| Total contract value | 21 paid months × £1,000 = £21,000 |
| Economic lifespan | 24 months (including 3 free months) |
| Monthly P&L | £21,000 ÷ 24 = £875.00 |
| Payments | £0 for months 1–3, £1,000 for months 4–24 |
4.2 Year 1 (Months 1–12)
P&L expense: 12 × £875 = £10,500
Cash paid: 9 × £1,000 = £9,000 (months 4–12)
Accrual: £10,500 − £9,000 = £1,500 (accrued expense)
Tenant Balance Sheet:
Assets: £0
Liabilities: Overdraft (£9,000) + Accrued expense (£1,500) = £10,500
Equity: −£10,500 (cumulative expense)
Check: A − L − E = 0 − (−£10,500) − (−£10,500) = 0 ✓During the free months, the tenant recognises expense with no cash outflow — the accrued expense builds. During the paid months, cash exceeds P&L — the accrual unwinds.
4.3 Year 2 (Months 13–24)
P&L expense: 12 × £875 = £10,500
Cash paid: 12 × £1,000 = £12,000 (months 13–24)
Cumulative: P&L £21,000, Cash £21,000, Accrual £0
Tenant Balance Sheet:
Assets: £0
Liabilities: Overdraft (£21,000)
Equity: −£21,000
Check: 0 − (−£21,000) − (−£21,000) = 0 ✓5. Proof of Concept: Lease Accounting
A company leases equipment costing £50,000 over 24 months at 1% monthly interest. This is the most complex area of accounting standards (IFRS 16), requiring recognition of a right-of-use asset, lease liability, depreciation, and interest expense.
5.1 Period Entry Setup
The Period Entry captures two overlapping economic lifespans within one transaction:
| Component | Value |
|---|---|
| Asset value (cost) | £50,000 |
| Use period | Start date → End date (the asset's economic life) |
| Lease payments | 24 monthly payments calculated via PMT function |
| Interest rate | 1% per month |
The system generates an amortisation schedule splitting each payment into interest and principal, then computes depreciation as work done over the asset's life.
5.2 Four Balance Sheets
The lease calculator produces four balance sheets for any reporting period — demonstrating how the same economic event appears with and without a lease, from both the lessee's and lessor's perspective:
| Perspective | With Lease | Without Lease |
|---|---|---|
| Buyer / Lessee | Right-of-use asset, lease liability, depreciation, interest expense | Fixed asset, overdraft, depreciation only |
| Seller / Lessor | Lease receivable, deferred income, interest income | Bank balance, revenue recognised over delivery |
In every case, the balance sheet equation (Assets − Liabilities − Equity = 0) holds for every reporting period. Depreciation is pro-rated when the reporting period is shorter than the asset's life. Interest is accumulated from the amortisation schedule. No adjusting journals are required — the system derives all values from the Period Entry's temporal data.
6. Proof of Concept: Revenue Recognition
Revenue recognition under IFRS 15 is the area that has undergone the most transformation in the last twenty years. The most complex example is a mobile phone contract where a handset and an ongoing service are bundled into a single payment stream.
6.1 The Scenario
A customer signs a 24-month contract at £45 per month. The standalone price of the handset is £600. The total contract value is £1,080. The service component is therefore £480 (£1,080 − £600).
IFRS 15 requires the two performance obligations to be identified and recognised separately: the handset at the point of delivery, the service over the contract period.
6.2 Period Entry Setup
One transaction, two revenue periods:
| Performance Obligation | Value | Recognition |
|---|---|---|
| Handset | £600 | Point-in-time: delivery date (day 1) |
| Service | £480 | Over time: 24 months (£20/month) |
| Payments | 24 × £45 = £1,080 | Monthly cash receipts |
6.3 First Month
Handset revenue: £600.00 (point-in-time, recognised on delivery)
Service revenue: £20.00 (1/24 × £480)
Total revenue: £620.00
Cash received: £45.00 (first monthly payment)
Accrual: £620.00 − £45.00 = £575.00 (receivable)
Revenue has been earned but cash not yet received.6.4 Month 12
Cumulative revenue: £600 + (12 × £20) = £840.00
Cumulative cash: 12 × £45 = £540.00
Accrual: £840.00 − £540.00 = £300.00 (receivable)
The receivable shrinks each month as cash catches up with recognised revenue.6.5 Month 24 (Contract End)
Cumulative revenue: £600 + (24 × £20) = £1,080.00
Cumulative cash: 24 × £45 = £1,080.00
Accrual: £1,080.00 − £1,080.00 = £0.00
Revenue and cash converge. No balance sheet item remains.7. What Period Entry Eliminates
| Double-Entry Requirement | Period Entry |
|---|---|
| General ledger | Not required — reports derived from transactions |
| Adjusting journals | Not required — accruals computed automatically |
| Month-end close | Not required — any period reportable in real time |
| Prepayment accounts | Not required — derived from cash ahead of work |
| Accrual accounts | Not required — derived from work ahead of cash |
| Deferred income accounts | Not required — derived from cash ahead of revenue |
| Depreciation schedules | Not required — derived from asset life overlap |
| Separate forecasting system | Not required — forward view embedded in transactions |
| Trial balance | Not required — balance sheet derived and self-checking |
8. Conclusion
Double-entry bookkeeping records values at points in time and then spends enormous effort correcting for the fact that economic reality is temporal. The general ledger, adjusting journals, the month-end close, the entire apparatus of prepayments, accruals, deferrals, and depreciation schedules — all exist because the underlying primitive does not record time.
Period Entry records time. The economic lifespan of the transaction is the data. The accrual — the heart of accounting — falls out as arithmetic: work done minus payments made. The balance sheet checks to zero not because an accountant forced it to balance but because the computation is complete.
This paper has demonstrated the method against three of the most complex areas of accounting standards: rent-free periods (IAS 17 / IFRS 16), lease accounting (IFRS 16), and multi-element revenue recognition (IFRS 15). In every case, Period Entry produces standards-compliant financial statements for any reporting period, without a general ledger, without adjusting journals, and without a month-end close.
The primitive is simple. The compliance is provable. The complexity that has accumulated around accounting for five hundred years is not inherent to the problem. It is an artefact of a system that does not record time.
Appendix: Period Entry Computation
A.1 Current Period Income or Expense
Earliest End = min(transaction end date, report end date)
Latest Start = max(transaction start date, report start date)
Overlap days = max(0, Earliest End − Latest Start)
Current value = overlap days ÷ total transaction days × valueA.2 Cumulative Income or Expense
Earliest End = min(transaction end date, report end date)
Total elapsed = max(0, Earliest End − transaction start date)
Cumulative = total elapsed ÷ total transaction days × valueA.3 Prior Period
Prior period = Cumulative − Current periodA.4 Accrual
Payments to date = Σ payments where payment date ≤ report end date
Accrual = Cumulative income/expense − Payments to date
If positive: accrued expense (work done, not yet paid)
or accrued revenue (revenue earned, not yet received)
If negative: prepayment (paid ahead of work)
or deferred income (received ahead of revenue)A.5 Balance Sheet Equation
Assets − Liabilities − Equity = 0
Where:
Assets = Prepayments (if cash > expense) or Receivables (if revenue > cash)
Liabilities = Cash paid (overdraft/bank) + Accrued expense (if expense > cash)
or Deferred income (if cash > revenue)
Equity = Cumulative P&L (negative for expenses, positive for revenue)