A software company provides a service in March but sends the invoice in April. The customer pays in May.
Which month should show the revenue?
For developers building billing systems, this question affects database design, reporting logic, and financial integrations. Service delivery, invoicing, and payment are separate events. Treating them as the same event can produce misleading reports.
Accrued revenue helps explain the gap between earning income and collecting it. Understanding this concept makes it easier to build systems that reflect what actually happened during a reporting period.
What Is Accrued Revenue?
Accrued revenue generally describes revenue that a business has earned but has not yet collected, often before invoicing.
Under accrual accounting, receiving cash is not the event that automatically determines when revenue is recorded. For customer contracts, IFRS 15 connects revenue recognition to satisfying performance obligations by transferring promised goods or services to the customer.
For a developer, the practical implication is clear: a payment timestamp cannot serve as the only source for a revenue report.
A system needs to distinguish between work performed, amounts billed, and money received.
A Simple Example
Imagine a development agency provides ongoing maintenance for a customer.
The agreement charges $3,000 per month. March maintenance is delivered throughout March. The agency sends its invoice on April 5 and receives payment on April 20.
Assume the agreement supports recognizing the full $3,000 as March revenue.
The timeline looks like this:
March: The agency delivers the maintenance service.
April 5: The agency issues the invoice.
April 20: The customer pays.
A report based only on invoice dates would place the amount in April. A report based only on payments would also place it in April.
Neither would show the revenue in March.
Revenue, Invoices, and Payments Are Different Records
Many early billing systems begin with two tables: invoices and payments.
That structure can support basic collections. However, financial reporting may require another layer that records revenue recognition independently.
An invoice describes what the customer has been billed. A payment records money received. A revenue entry records an amount recognized for a particular period.
These records can have different dates and amounts.
For example, an annual invoice might cover services delivered across twelve months. Another agreement might allow monthly revenue recognition while billing happens quarterly.
Keeping these concepts separate gives the system room to handle both situations.
Accrued Revenue Versus Accounts Receivable
A common shortcut is to say that accrued revenue becomes accounts receivable when an invoice is issued.
That may describe an operational workflow, but invoice status alone does not determine the accounting classification.
Under IFRS 15, a receivable represents an unconditional right to consideration. A contract asset represents a right that remains conditional on something beyond the passage of time. An unbilled amount can therefore already be a receivable.
For software design, store billing status separately from accounting classification.
An invoice_created flag should not automatically decide whether a balance is a contract asset or a receivable.
Understanding the Journal Entries
Consider the maintenance example again.
Assume the business records March’s earned but unbilled amount in an asset account called “Unbilled receivable.”
The illustrative March entry is:
Account
Debit
Credit
Unbilled receivable
$3,000
Maintenance revenue
$3,000
When the invoice is issued, the business moves the amount into its billed receivable account:
Account
Debit
Credit
Billed accounts receivable
$3,000
Unbilled receivable
$3,000
When payment arrives:
Account
Debit
Credit
Cash
$3,000
Billed accounts receivable
$3,000
The invoice and payment entries do not recognize the same revenue again.
Actual account names and posting workflows depend on the organization’s accounting setup.
Why Duplicate Revenue Happens
Duplicate recognition often appears when separate workflows operate without a shared reference.
A monthly process records earned revenue. Later, an invoice integration credits revenue again because its default behavior assumes every invoice represents new income.
The result is two revenue entries for one service.
Prevent this by linking recognition entries to the underlying contract, service period, and invoice allocation.
Before posting an invoice, the workflow should determine whether any related revenue has already been recognized.
The accounting treatment should come from approved rules rather than assumptions embedded in an integration script.
Designing a Useful Data Model
A practical model can include separate records for:
Customer contracts.
Services or performance obligations.
Service delivery periods.
Revenue recognition entries.
Invoice lines.
Payment allocations.
Journal entries.
Each revenue entry should identify its source and accounting period.
Useful fields include the contract identifier, service period, recognized amount, currency, posting status, and journal reference.
Relationships matter as much as fields. One invoice line may relate to several recognition entries. One payment may settle several invoices.
Avoid forcing every relationship into a single invoice record. That approach becomes difficult to maintain as billing arrangements grow.
Do Not Recognize Revenue from Activity Alone
A completed task or logged hour does not automatically establish that revenue should be recognized.
The contract and applicable accounting policy determine the treatment.
Some arrangements support recognition over time. Others require recognition at a particular point. For obligations satisfied over time, IFRS 15 requires an appropriate measure of progress.
Developers should therefore avoid a universal rule such as “completed task equals revenue.”
Instead, let the application capture reliable operational evidence. Finance-approved rules can then determine how that evidence affects recognition.
This separation makes the system easier to review and update.
Building a Reliable Period-End Process
A period-end workflow should identify eligible contracts and calculate proposed entries for review.
Keep draft calculations separate from posted journals.
A useful sequence is:
Select the reporting period.
Gather service delivery evidence.
Apply the approved recognition rules.
Compare against previously posted amounts.
Review exceptions.
Approve and post the adjustment.
Store enough detail to explain each calculation later.
If someone asks why a particular amount appeared in March, the system should show the source records and rule used.
Handling Retries and Corrections
Scheduled jobs can fail halfway through a batch. Users can also submit the same action twice.
Use a unique posting reference to prevent duplicate entries during retries.
Corrections need equal care. Once a journal has been posted, silently changing its amount can break the audit trail.
A more traceable workflow records an approved adjustment or reversal and links it to the original entry.
Also define how late information affects closed periods. The application should follow the organization’s period controls rather than automatically rewriting historical reports.
Conclusion
Accrued revenue highlights an important design requirement: earning, billing, and collecting money need separate treatment.
Build clear relationships between contracts, delivery records, invoices, and journals. With reliable evidence and approved accounting rules, billing software can support accurate reporting while remaining easier to explain, review, and maintain.
