Illustration of transaction documents, two sides of a ledger, and reports on a desk.

I Think of Accounting as a Business Database

A hypothetical THB 10,000 service shows how accounting rules organize data and how business dimensions help us analyze it.

October 25, 2026 by

Tomz

To know how much a customer still owes, or which period today’s payment relates to, we have to look back at what happened. What interests me about accounting systems is how they keep those facts as a classified, explainable history of events.

That is why I think of an accounting system as a business database. It records what happened, what it affected, and when it belongs in a report. Seen this way, accounting is close to information-system design, except that every record also carries accounting meaning and rules.

How a business event becomes a journal entry

Consider a fictional equipment-repair shop. It completes a THB 10,000 service for a customer in the first period and collects payment in the next. For this example, the conditions for recognizing revenue have been met and the right to payment is unconditional except for the passage of time, so the shop uses accounts receivable.

On recording the entry, accounts receivable rises and the shop recognizes service revenue, even though no cash has arrived. When it later collects the full payment, it increases cash and reduces the receivable from the original entry. That later collection does not create service revenue a second time.

I like how accounting separates the meaning of an event from the movement of money. Completed work, a right to payment, and cash actually received are related but can occur at different times. Classification lets us ask more precise questions than a list of cash in and out can answer.

This example shows only the revenue, receivable, and collection mechanism. It leaves VAT, withholding tax, costs, and other entries out of the model. It is not a calculation of net profit, tax, or the whole company’s financial statements.

The useful check built into double-entry accounting

What I find clever is that an event is not recorded on only one side. Double-entry accounting requires total debits to equal total credits for an entry. Even on paper, we can use that equality to check the amounts without waiting for a computer to calculate them.

To write this as a mathematical check, I might assign a plus sign to debits and a minus sign to credits. The sum must be zero. This is only a sign convention for checking the two sides. It does not mean a debit always brings in cash or increases a balance, or that a credit always sends cash out or reduces a balance.

Hypothetical entries, in THB. Plus and minus signs in the check column only reflect the chosen debit-plus, credit-minus convention.
Event	Debit	Credit	Two-side check
Recognize service provided on credit	Accounts receivable 10,000	Service revenue 10,000	+10,000 − 10,000 = 0
Collect payment later	Cash 10,000	Accounts receivable 10,000	+10,000 − 10,000 = 0

In the first entry, debiting receivables increases receivables, while crediting revenue increases revenue too. In the collection entry, crediting receivables reduces receivables. Whether an entry increases or decreases a balance depends on the account type and transaction, not only on my signs for checking. A zero check total does not make every account balance zero.

Suppose instead that the first entry debits cash rather than receivables, although no money has arrived. Crediting the same amount of revenue would still balance the two sides. This is a separate example of recording the wrong account, not another entry added to the correct sequence above.

Or an entire entry could be missing, and the remaining entries might still balance. The same is possible with some entries that misstate reality or involve fraud. Thus balance does not establish correctness, completeness, or compliance. We must still compare entries with the actual events and supporting evidence. The mathematical check is valuable, within its limits.

Conceptual illustration linking a service document and payment envelope to two-sided ledgers, then to two reports — A conceptual path from source documents through the ledger to reports. It has no numeric scale and shows neither documents nor actual performance from a real business.

Transaction history and a snapshot answer different questions

From the transaction history, including opening balances and relevant adjustments, we can ask different questions. A receivables balance at the end of the first period is a position at one date. Revenue for that first period is what was recognized across a span of time. The reports use related data but have different time meanings.

The same service viewed in different periods shows different sides of the story

Period when service is provided

This entry increases end-of-period receivables by
THB 10,000

This entry increases the period’s service revenue by
THB 10,000

Next period, when payment is collected

Cash rises by THB 10,000
Receivables fall by THB 10,000

New revenue from this collection
THB 0

Only this hypothetical transaction is shown, not the whole company’s balances or profit. Recognition and collection can fall in different periods.

There is another time distinction: the date an entry takes effect for accounting and the time someone enters it into the system. A person might post after the underlying event occurred, but the click time does not decide which reporting period the entry belongs in. We must consider the event, recognition conditions, and applicable requirements; a date cannot be backdated at will.

If the system stores both the accounting date and the entry timestamp, we can see which period the event was assigned to and when it was entered. Corrections to entries or data in a closed period also require the applicable rules and controls, not just a changed date.

Thinking of a position at one date helps me understand the statement of financial position. But that snapshot is built from classified, measured, and adjusted data, including some estimates. Accounting is therefore not an immutable event log, nor does it hold every piece of raw business data.

Accounting standards through a systems designer’s eyes

From a systems perspective, I see accounting standards as requirements governing how events become accounting information. I picture a pipeline: receive events and evidence, check and classify them, assess recognition and measurement, then post entries and prepare reports.

When I compare a standard with a filter or function, I mean the steps that check conditions and organize information by meaning, such as which period an item belongs in or how it should be presented. Source events and evidence can still be kept even when revenue-recognition criteria are not yet met. The analogy clarifies what rules do; it does not claim that a standard is one software function.

A conceptual information pipeline with standards and judgment applied at several points

Events and evidenceSource information to check
Check and interpret entriesClassify, recognize, and measure
Posted entriesRecord both sides and check balance
Present reportsGroup, display, and disclose

These steps may need revisiting. Estimates, adjusting entries, and disclosures may come later. Standards apply both before and after posting, with judgment still required.

Applicable standards set principles a business must follow. Accounting policies are the specific principles and practices it selects within those requirements. Available choices can vary with facts and the standards the business uses. The Conceptual Framework for Financial Reporting explains the underlying ideas, but it does not replace or override a specific standard.

Judgment still matters, especially when interpreting facts and estimates. A system that calculates and checks conditions does not remove responsibility for what the data means. Designers should understand which accounting principle a field or rule is meant to support.

Use the same accounting data to answer the right question

Once entries exist, analysis starts with choosing what to measure. To ask about service revenue, select the revenue account and relevant period and use recognized revenue as the measure. The earlier debit-plus, credit-minus sum to zero checks balance. It serves a different purpose from calculating revenue.

Analytic accounting is one way to attach management dimensions to entries. Tag the THB 10,000 of service revenue recognized in the first period as Repair Project A in the Service Department. Looking by either project or department still shows THB 10,000 from that same entry. Do not add the two views together as though they created new revenue.

In data-system language, a tag or label says what an entry relates to. A view selects and displays data to answer a question. A cube summarizes measures across several dimensions, such as revenue by project and department. They serve different functions even when combined, and systems can store or aggregate them differently.

Adding a dimension does not create revenue or replace recognition principles. Balances in the main general ledger must still be grounded in valid entries. Changing an analytic tag or category is different from changing an accounting amount or recognition decision, which needs its own reason and controls.

For me, the system-design questions therefore stretch from the source event to the report: What event produced this number? Which period is it in? Which rule applies? Which dimension am I viewing it through? Before adding another view, do we know what the number actually counts?