Transaction Data
Transaction data is process- and time-related data created by individual business events – such as orders, delivery notes, invoices or stock postings. It documents what happened when and to which master data, and changes with every new event.
Transaction data is the process- and time-related data created during day-to-day operations by individual business events, each documenting one specific transaction. Typical examples are a customer order, a goods receipt, a delivery note, an invoice or a stock posting. Unlike master data, which is permanently valid and reusable across many transactions, transaction data always relates to a single event at a specific point in time – it records who did what, when, and with which quantities, prices and parties involved.
Transaction data is not self-contained but draws on master data: an order references an item from the item master, a customer from the customer master and, where applicable, a supplier. Only through this linkage does a document become complete. Because transaction data is created continuously, it grows quickly and makes up the largest share of the data volume in an ERP system. It is the basis for analyses, stock levels, accounting and the full traceability of business processes.
At a glance
- Process- and time-related data from individual business events
- Created continuously and accounts for the bulk of ERP data volume
- Draws on master data (item, customer, supplier) – never the other way around
- Examples: order, delivery note, invoice, stock and accounting posting
- GoBD-relevant in the DACH region: unalterable and usually retained for 6–10 years
Transaction data vs. master data – the distinction
The best way to understand transaction data is through its contrast with master data. Master data is long-lived base data that describes a business partner or an object and rarely changes – for example a customer’s name and address, an item number and product name, or a supplier’s bank details. It exists independently of any specific transaction and is drawn upon again and again across many transactions.
Transaction data, by contrast, is only created by a business event and describes exactly that one transaction: the order of 20 units on 3 March, the goods receipt on 7 March, the invoice with a specific amount and date. It is therefore dynamic, event-bound and generally not reusable. A useful rule of thumb: master data states "who" and "what" exists, while transaction data states "when", "how much" and "what happened".
Why the separation matters so much
A clean separation of the two data types is the foundation of a consistent data model. Master data is maintained centrally and stored correctly once; transaction data adopts these values by reference instead of duplicating them. If a master address later changes, documents already created remain historically correct, because they capture the state that was valid at the time of the transaction. This freedom from redundancy avoids contradictions and is a prerequisite for reliable analyses.
How transaction data is created and structured
Transaction data is created wherever a business process generates a document or a posting. In sales these are quotes, orders, delivery notes and outgoing invoices; in purchasing, purchase orders, goods receipts and incoming invoices; in the warehouse, inbound, outbound and transfer postings; and in financial accounting, the journal entries on the accounts. Incoming payments, returns, production orders and time bookings also belong here.
Structurally, a typical transaction record consists of a document header and several line items. The header holds overarching information such as document number, date, document and transaction type, and the references to the master data involved – for example the customer. The line items contain the individual rows with item, quantity, unit price and tax rate. Added to this are technical metadata such as creation time, editor and status. This structure allows transactions to be linked seamlessly along the process chain: an order becomes a delivery note, which becomes an invoice – each referencing the preceding document.
Transaction data in the ERP system
In an ERP system, transaction data is the moving part of the central data model. Because ERP software maps processes across modules, a transaction entered once takes effect in all affected areas: a posted outbound goods delivery reduces the stock level in inventory management, creates the basis for the invoice in sales, and supplies the figures for the posting in financial accounting. This continuity is precisely the benefit of an integrated system – transaction data flows from module to module without media breaks.
Transaction data also feeds the entire reporting: revenue statistics, open items, stock coverage, contribution margins and liquidity planning all rest on the aggregation and condensation of individual transactions. Because this data arises quickly and in large volumes, topics such as performance, archiving and audit-proof storage are closely tied to it. Older, completed transaction data is often offloaded or archived to keep the operational database lean, yet remains available for evidentiary purposes.
Role in migration and data transfer
When switching ERP systems, master and transaction data are treated differently. Master data is usually migrated in full so the new system is immediately operational. Transaction data, by contrast, is often only transferred in part – for example open orders, open items and opening stock as of the cut-off date – while completed legacy transactions remain in the old system or in an archive. A complete transfer of historical transaction data is costly and rarely necessary, but can make sense for tax or analytical reasons.
Why transaction data matters to the business
Transaction data is the memory of the ongoing business. Without it, you could neither trace which goods were delivered to which customer, nor which payments are outstanding or how revenue is developing. It makes processes controllable: only the condensed analysis of many individual transactions reveals bottlenecks, trends and deviations and supplies the figures for operational and strategic decisions.
Its quality directly determines the reliability of these analyses. Faulty or incomplete transaction data – wrongly posted quantities, duplicate documents, missing assignments – propagates into stock levels, balance sheets and key figures. That is why ERP systems rely on clear capture rules, validations and linkages, so that every transaction is recorded correctly and only once and the data basis remains consistent.
DACH specifics: retention and unalterability
In Germany, Austria and Switzerland, transaction data – insofar as it reflects tax-relevant business events – is subject to strict retention and evidence obligations. In Germany, the GoBD, together with the Fiscal Code (Abgabenordnung) and the Commercial Code (HGB), stipulate that data relevant to accounting must be stored in an unalterable, complete and traceable manner. A once-posted document may not be overwritten without a trace – corrections are made via traceable reversal or adjustment postings.
In Germany, retention periods for accounting documents and invoices are generally eight years – shortened from the previous ten years at the end of 2024 (§ 147 AO); ten years still apply to items such as books, inventories and annual financial statements, and shorter periods of six years to certain commercial and business letters. For companies this means: transaction data must remain machine-analyzable and available for a tax audit throughout the entire period. This is precisely why ERP systems offer audit-proof archiving, posting locks after period closing, and logging of all changes. Anyone switching systems must ensure that this historical data remains readable and verifiable.
Example
Example: an order passing through the transaction data
An electronics wholesaler receives an online-shop order for 15 routers. This creates the first transaction record in the ERP system: an order that references the customer from the customer master and the item from the item master, supplemented by quantity, price and order date. The master data itself remains unchanged – the order merely uses it as a reference.
From the order, a delivery note (goods issue reducing stock by 15 units) and an invoice are generated in sequence, each as a separate document linked to its predecessor. The incoming payment is posted as a further transaction. At year-end, these and thousands of similar transactions add up to revenue, cost of goods and open items – while remaining verifiable as individual, unalterable documents for a tax audit.
Frequently asked questions
Related services
Sources
Questions about Transaction Data in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.