REA Accounting Data Model Template (Resources, Events, Agents)

Every business owner in Saudi Arabia starts with the traditional general journal, recording sales and expenses in debit and credit columns, only to discover after a year or two that this approach is no longer enough. You know how much you sold, but not to which customer, at which branch, or which supplier was behind it. You know how much you paid in salaries, but not how many work hours corresponded to each riyal. The numbers are there, but the relationships between them are missing.

The REA data model (Resources, Events, Agents) is a modern accounting answer to this gap. Professor William McCarthy proposed it in 1982 as an alternative to the double-entry journal inside computerized systems, and it rests on a very simple idea: every economic transaction in your company consists of just 3 elements, a resource that flows in or out, an event that moves that resource, and a human or institutional party behind the event. This triad is enough to generate every accounting report you need, with the added benefit that the data stays connected to the customer, employee, product, and branch.

In this guide, we explain the REA model in practical language for a Saudi business owner and accountant, from the theoretical roots to its application inside the sales cycle and the expenditure cycle, through its link to Phase 2 e-invoicing, all the way to how Qoyod embodies it inside the system without asking you to learn a new accounting theory. The attached template helps you draw a REA model for your company on a single worksheet before you move it into any ERP system.

What is the REA Data Model and Who Created It

REA is an acronym for three words: Resources, Events, Agents. It is an accounting data model introduced by Professor William McCarthy at Michigan State University in 1982, in a research paper titled “The REA Accounting Model” published in The Accounting Review. The core idea was that the double-entry journal was designed in the 15th century to serve paper ledgers, and that modern databases can store accounting information in a much richer way without needing to abstract it into debit and credit columns.

In the traditional model, when you sell a product worth 1,000 SAR, the system records in the journal: debit accounts receivable 1,000, credit sales 1,000. This entry is accurate from an accounting standpoint, but it drops important information: who is the customer? Who is the employee who closed the sale? Which exact product? From which warehouse? At what time? These details are stored in supporting tables, but the link between them and the accounting entry stays weak.

REA flips the equation. Instead of an entry followed by details, it starts from the economic event itself (a sale of 1,000 SAR), and links it directly to the resource (the product delivered and the cash received) and to the agents (the customer and the seller). The accounting entry is generated later, automatically, from this data. The result: one database that serves accounting, sales, inventory, and HR with no duplication.

The Theoretical Root

McCarthy built on the Entity-Relationship model developed by Peter Chen in 1976 for databases. Chen’s idea was that the world consists of entities and relationships between them, and that any information system should reflect this structure rather than invent a parallel one. McCarthy applied this to accounting: there are three economic entities (resources, events, agents), and the relationships between them are enough to generate everything the accountant needs.

Adoption

Since the 1990s, the major ERP systems have adopted REA concepts without naming them as such. Every modern accounting system you use today, including Qoyod, stores data in a pattern close to REA and generates the journal as a reporting layer on top of it. You record a sale to a customer in the system, and the double entry appears in the journal automatically, without you writing it by hand.

Why Modern ERP Replaces the Journal with the REA Model

The double-entry journal is a brilliant 15th-century invention, but it carries limitations that become obvious when you move from paper to software. The first is that the accounting entry is an abstraction, dropping the operational dimension of the event and keeping only the financial trace. The second is that the link between the entry and customer or product data happens through side tables, creating constant duplication between accounting records and sales and inventory records.

REA solves these limitations in two practical ways. First, by removing redundant side tables. Instead of a customer table in the sales module and a duplicate customer table in the accounting module, there is a single agents table used by everyone. Second, by storing the economic event as it actually happened, with all its details, and then extracting the accounting entry from it when needed. If you need a non-financial report (for example, how many customers bought a certain product last quarter), you extract it from the same data without reaching into other tables.

• One data layer: the customer, the product, and the employee exist once in the system, and the accountant, the salesperson, and the warehouse keeper all use the same record.
• Flexible reporting: because data is stored with its full detail, you can generate financial and non-financial reports from the same source.
• Tracking accuracy: every economic event carries a precise timestamp and a responsible party, which makes internal and external auditing easier.
• Alignment with e-invoicing: the Zakat, Tax and Customs Authority (ZATCA) Phase 2 requirements call for detailed data on each invoice, and REA stores this data natively.
• Scalability: when you add a new module (CRM, project management, HR), it connects to the same agents and events database without duplication.

The Three Components in Detail: Resources, Events, and Agents

Before you build a REA model for your company, you need to understand precisely what each of the three words means, because almost every error in applying REA comes from mixing up these categories.

Resources

Everything of economic value in your company that can be acquired, consumed, or transformed: the products and services you sell, the raw materials you buy, cash in tills and banks, accounts receivable from customers, accounts payable to suppliers, fixed assets (equipment, vehicles, furniture), and even employee work hours count as a resource. The condition is that it must be measurable in financial terms.

Events

Any economic transaction that moves a resource. A sale is an event, a purchase is an event, receiving cash is an event, paying a salary is an event, receiving goods into the warehouse is an event, converting raw materials into a finished product is an event. An event in REA always has two reciprocal sides (Duality): an event that takes in a resource is matched by another event that gives out a resource in return. For example, selling a product (an event releasing the “goods” resource) is matched by receiving cash (an event bringing in the “cash” resource).

Agents

Every person or entity with a role in the event. They split into two types: internal (your employee who carried out the event, for example the salesperson or warehouse keeper) and external (the other party, for example the customer or the supplier). Every event in REA must carry at least an internal agent and an external agent, so you know who executed and with whom.

How to Build a REA Model for Your Company Step by Step

Building a REA model for your company does not require programming or a database in the first stage. It is enough to take a worksheet (the attached template) and walk through your main business cycles one by one. From each cycle, you come out with three lists: a list of resources, a list of events, and a list of agents.

Step 1: Identify Your Economic Cycles

Any company, small or large, consists economically of 4 to 6 cycles: the revenue cycle (sales and collection), the expenditure cycle (purchase and payment), the production cycle (if manufacturing exists), the payroll and HR cycle, the financing cycle (loans and capital), and the fixed assets cycle. Start with your two most important cycles, usually revenue and expenditure.

Step 2: For Each Cycle, List the Events

In the sales cycle, for example: receiving a customer order, confirming the order, preparing the goods from the warehouse, shipping or delivering them, issuing the invoice, receiving payment. Not all of these events need to be accounting events in the classical sense, but they are all economic events the system cares about.

Step 3: For Each Event, Identify the Moving Resource

Preparing the goods moves the “inventory” resource (out). Issuing the invoice creates a new resource called “accounts receivable” (in). Receiving the payment moves the “cash” resource (in) and removes the “accounts receivable” resource (out).

Step 4: For Each Event, Identify the Agents

The internal agent is from your team (salesperson, accountant, warehouse keeper). The external agent is the customer, supplier, or bank. Always ask: who on our side executed this event? And with whom?

How REA Relates to the Revenue and Expenditure Cycles

The revenue and expenditure cycles are the backbone of any company, and they are the clearest places to apply the REA model because they mirror each other. Everything that happens in your revenue cycle happens at the supplier in reverse in their expenditure cycle. This view helps you design your system symmetrically, cutting half the work.

The Revenue Cycle

It starts the moment an order is received and ends with closing the receivable when the full payment lands. The main events: receiving the order, preparation, shipping, issuing the tax invoice (with QR code and XML per ZATCA requirements), receiving payment, closing. Every one of these events moves a resource, creates one, or removes one.

The Expenditure Cycle

A mirror image of the revenue cycle. It starts with identifying a need and ends with closing the payable after paying the supplier. The events: internal purchase request, approval, sending a purchase order to the supplier, receiving the goods, receiving the supplier’s invoice, booking the payable, payment. Notice the symmetry: what you receive in revenue, you pay in expenditure, and vice versa.

The Duality Rule

Every “economic” event in REA carries its duality: an event that brings in a resource is matched by an event that releases a resource. This rule is the modern alternative to “for every debit a credit” in double-entry bookkeeping. Example: selling goods for 5,000 SAR including VAT 15% generates two events: an event that releases “goods at a cost of 3,500 SAR” and an event that brings in “a receivable worth 5,000 SAR”. This duality ensures the system is accounting-balanced, exactly as the debit and credit rule does in the traditional ledger.

The Difference Between REA and Double-Entry Bookkeeping

A question every accountant asks when first hearing about REA: does this eliminate double-entry bookkeeping? The short answer: no, it absorbs it. Double-entry bookkeeping becomes a reporting layer on top of the REA model, not the underlying data storage structure.

At the Storage Level

In the traditional system, data is stored directly as journal entries: date, debit account, credit account, amount, narration. Other details (customer, product, employee) are kept in side tables and linked to the entry via keys. In REA, data is stored as economic events, and each event carries: date, type, internal agent, external agent, moving resource, quantity, value. The accounting entry is extracted automatically.

At the Reporting Level

Both models generate a journal, a general ledger, a balance sheet, and an income statement. The difference is that REA can generate non-financial reports just as easily: the number of orders per customer, the average preparation time, productivity per employee. The traditional system needs additional tables for these reports.

At the Flexibility Level

When you add a new dimension (a new branch, a product line, a different currency), the traditional system needs changes to the chart of accounts and the reports. REA absorbs the new dimension as an extra field in the events and agents tables without structural changes.

• Double-entry bookkeeping: a financial abstraction of the event, keeping the financial trace and dropping the operational details.
• REA: stores the event with its full details and generates the financial entry on demand.
• Double-entry bookkeeping: excellent for classical financial reports.
• REA: supports financial and non-financial reports from the same source.
• Double-entry bookkeeping: needs auxiliary tables to link the entry to the customer and the product.
• REA: relationships are built into the data structure itself.

Applying REA to a Saudi Company: A Complete Retail Store Example

Let us take a hypothetical retail store in Riyadh called “Al Nada Home Appliances Establishment”, selling electrical and home appliances across three branches (Riyadh, Jeddah, Dammam) with 12 employees. We will draw the REA model for all its cycles in one session.

Resources

Products (appliances across 50 SKUs), cash in branch tills, cash in bank accounts (3 accounts), receivables (installment sales), payables (with 8 suppliers), inventory in the central warehouse and at each branch, fixed assets (storefronts, delivery trucks). Each resource has a unique identity in the system, so even if the same product exists in 3 branches, each branch’s stock is treated as a separate balance.

Events

In the revenue cycle: direct cash sales at the branches, installment sales, delivery to an address, issuing a Phase 2 tax invoice, receiving payments. In the expenditure cycle: purchases from Saudi and Gulf suppliers, receiving goods at the central warehouse, distributing them to branches, paying suppliers. In the HR cycle: clocking attendance, calculating salary, transferring through Mudad, paying allowances.

Agents

Internal agents: general manager, 3 branch managers, 6 salespeople, central warehouse keeper, accountant, HR specialist. External agents: 1,200 registered customers, 8 suppliers, 3 banks, ZATCA, the General Organization for Social Insurance (GOSI), Mudad, Qiwa.

One Event Scenario in Detail

A customer named “Khalid Al Otaibi” buys a refrigerator from the Riyadh branch for 4,600 SAR including VAT 15% (4,000 SAR before tax + 600 SAR tax), paying through Mada. The event is recorded in REA as follows: event type “cash sale”, date, external agent “Khalid Al Otaibi”, internal agent “Ahmed the salesperson”, outgoing resource “Samsung refrigerator model RT38” quantity 1 at a cost of 3,000 SAR, incoming resource “cash at Al Rajhi Bank” amount 4,600 SAR, tax 600 SAR, branch “Riyadh”. The balanced accounting entry is generated automatically from this data: debit Al Rajhi Bank 4,600, credit sales 4,000, credit VAT 600, debit cost of goods sold 3,000, credit inventory 3,000.

Extracting the Balance Sheet and Financial Statements from the REA Model

The practical question every accountant raises: if the data is stored as events, resources, and agents, how do I extract the balance sheet, the income statement, and the cash flow statement? The answer is that the system reads the same data in different ways for each report.

The Balance Sheet

It is built from the resources. The system aggregates all resources held at a specific date: cash, receivables, inventory, fixed assets (the debit side), payables, loans, equity (the credit side). Each resource is calculated from its cumulative events. For instance, the inventory balance for a given product is the total of “receipt” events minus the total of “issue” events.

The Income Statement

It is built from events within a period. Sale events are summed to give revenue, purchase and inventory issue events give cost of goods sold, and salary and rent events give operating expenses. Each event carries its date, so the system filters by the required period.

The Cash Flow Statement

It is built from cash events alone. The system pulls every event that moved the “cash” resource, separates them by activity type (operating, investing, financing), and presents the net.

REA and Phase 2 E-Invoicing

The Zakat, Tax and Customs Authority launched Phase 2 of e-invoicing in December 2022, and the rollout extended in waves to all eligible establishments. Phase 2 requirements are demanding in terms of data: every invoice must carry an XML containing detailed seller and buyer information, product lines and tax fields, alongside a digital signature and a QR code. The invoice must be sent to the Fatoora platform before delivery to the customer (in B2B) or immediately after issuance (in B2C).

The REA model handles these requirements smoothly because the data the authority asks for already exists in its structure. The seller field is the “internal agent”, the buyer field is the “external agent”, the product fields are the “moving resources” in the sale event, and the tax field is calculated from the resource value. A system that applies REA can generate the required XML from the same event data without asking the accountant to enter it twice.

How Qoyod Applies the REA Model Inside the System

Qoyod is a Saudi accounting system approved by ZATCA, designed from inception on a data structure aligned with REA logic, without requiring the user to learn the model. You record a sales invoice for a customer, and the system stores: the event (sale), the external agent (customer), the internal agent (user), the moving resources (products), the values, the date, the branch, and every detail you may need later.

This design shows up in 3 features you use daily inside Qoyod. First, the customer ledger is linked directly to every event, so opening a customer file shows the full history (orders, invoices, collections, messages) without separate reports. Second, inventory is linked to purchase and sale events in real time, so any sale deducts the quantity from the stock automatically. Third, the journal is generated as a reporting layer, so you see the double entry prepared per the Saudi standard without writing it manually.

You can experience this firsthand by opening an account on Qoyod and recording the first 5 invoices from your business. You will notice that each invoice automatically produces: an inventory update, a journal entry, a customer balance update, an entry in sales reports, and, if you are in Phase 2 of e-invoicing, an XML submission to the Fatoora platform. All of this from a single event you recorded.

For the accountant who wants to go deeper, Qoyod offers accounting reports that surface the different layers of REA: sales reports by customer (agents), by product (resources), by branch (additional dimensions), and by employee. All these reports run off the same recorded event data.

Common Mistakes in Applying REA

When applying REA to an existing company, recurring mistakes show up. Knowing them in advance saves you months of rework.

Mixing Resources with Events

The most common mistake. Someone writes “Sale” in the resources list, even though a sale is an event, not a resource. The rule: a resource is something that “exists” and can be measured at a given moment (inventory balance today, cash balance today). An event is something that “happens” during a time (a sale made today at 11 am).

Skipping the Internal Agent

Some companies record only the customer’s name on each event and forget to record the salesperson’s name. This drains half the value of REA. The internal agent is essential for productivity reports and performance accountability.

Treating Every Action as an Economic Event

Not everything that happens in the company is an economic event in the REA sense. Sending a price quote is not an economic event (no resource has moved yet), printing an invoice is not an economic event. An economic event must actually move a resource.

Over-Tiering Agents

Trying to classify customers into 7 or 8 categories inside the agents ledger. It is better to keep the ledger simple (customer, supplier, employee, bank, government body) and use additional attributes for detail.

Ignoring the Duality Rule

Recording a “sale” event without recording its matching event (collection or creation of a receivable). Every event bringing in a resource is matched by an event releasing a resource. Ignoring this rule breaks the accounting balance.

When REA Fits and When You Need a Simpler System

REA is not a solution for every company. It fits very well for companies whose size demands tracking complex relationships among customers, products, and employees. But if you own a single shop with simple traffic, a point-of-sale (POS) system connected to a traditional journal may be enough for you.

REA Fits Very Well in These Cases

A company with more than one branch or product line needing cross-cutting reports, a company operating under Phase 2 e-invoicing requirements that needs detailed data per invoice, a company with a sales team that wants to measure each salesperson’s productivity, a company planning to grow and wanting a data structure that will not need a rebuild as it expands, and a company running a CRM, an inventory system, and accounting that wants to unify the data.

A Traditional System May Be Enough in These Cases

A small shop with a single branch, limited products, and few customers, a simple services company with stable sales figures, or a short-term seasonal business. The difference between the two models at this scale does not make a practical difference, and REA’s flexibility is not exploited.

To compare the options and the cost of each plan and how much data you can store, see the Qoyod pricing page. Qoyod’s plans cover everything from startups to multi-branch companies, all built on the same modern data structure.

Frequently Asked Questions

Does REA eliminate the need for an accountant?

No. REA eliminates manual entry of journal entries, but it raises the value of the accountant’s role. In a REA environment, the accountant moves from writing entries to analyzing data, understanding patterns, and making decisions. You need an accountant who understands your business and makes sure that events are recorded correctly and that the reports reflect reality.

Can I apply REA manually before acquiring a system?

Yes. The attached template helps you draw a REA model for your company on a worksheet. You will identify your resources, events, and agents, then you can transfer this design to any ERP system you choose later. This preparatory step cuts months off the implementation.

Is REA compatible with Saudi and international accounting standards?

Yes. REA is a data layer, it does not conflict with standards. The financial statements generated by any system applying REA comply with the IFRS standards adopted in Saudi Arabia and with ZATCA requirements. The only difference is in how the data is stored internally.

How long does it take to build a REA model for a mid-sized company?

The initial drafting on a worksheet takes between two and four sessions of about an hour each, depending on the complexity of your cycles. Application inside a system (such as Qoyod) does not need extra time, because the system is built on REA structure from the start, you only enter your company data. Building a custom system from scratch may take months.

What is the difference between REA and ERP?

REA is a data model, ERP is a category of software. ERP stands for Enterprise Resource Planning, which is a program that manages accounting, inventory, sales, and HR. Most modern ERP systems, including Qoyod, use a data structure close to REA without announcing it. REA is “how the data is stored”, and ERP is “the program through which you interact with this data”.

Do I need programming knowledge to apply REA?

No. As a business owner or accountant, you only need to understand the three concepts (resources, events, agents) and how to map them onto your cycles. The technical implementation inside the system is done by the system itself. The attached template needs no programming knowledge, you just fill in the cells.

How does REA help me prepare for a ZATCA audit?

A ZATCA audit looks for consistency between issued invoices, inventory balances, cash balances, and tax reports. In a REA environment, every invoice is an event with a moving resource and an external agent. During an audit, the system can trace any invoice from the QR code in the XML to the stored event, to the moving product in inventory, to the payment received at the bank. A complete chain without gaps.

Does REA support multiple currencies and branches?

Yes. Resources in REA carry their own attributes (currency, branch, location, quantity). A company with a branch in Riyadh and a branch in Dubai can record events in their local currencies, and the system handles conversions according to exchange rates at the event date. Your consolidated reports show the figures in the home currency.