Methodology

How Actuals validates that transactions are recorded consistently across systems, and how matching and explanations work.

Goal

Setting up Actuals for a company determines whether transactions appear consistently across several main systems. A transaction is anything with at least timestamp, transaction id, and amount — not only ecommerce orders. Examples include supplier invoices, accounting statements, hours logs, and other custom entities.

Those systems appear as sources. Data can enter Actuals by:

Connector collection from an external system

Direct send via the Actuals API

Files on the Actuals SFTP server

Upload through the user interface (Import › Files)

Details live under

Import and method guides under

Data integration.

Matching

A matching package (configured under Reconciliation › Setup › Matching Packages) defines an expected relation between one set of sources and another on a transactional level. Actuals focuses on managing exceptions to that relation.

Example: compare order data with Payment Service Provider (PSP) data. Every order should be paid for with the same amount in the PSP. Actuals matches transactions across both sides, reports package status, shows exception impact, and lists individual non-matching rows.

Multiple sources can sit on either side of a package. Matching sums amount per transaction id in the first group and in the second group. If the totals are equal, those rows match.

Example

Matching package compares sources A and B with C and D:

transactionid	timestamp	source	amount
123	10-1-2023	A	10
123	20-1-2023	C	10
124	20-1-2023	A	20
124	20-1-2023	B	30
124	30-1-2023	C	5
124	30-1-2023	D	45
125	10-2-2023	A	10
125	10-2-2023	D	30
125	10-2-2023	D	-20

All nine rows match: 123 totals 10 on both sides; 124 totals 50 vs 50; 125 totals 10 vs 10. Missing rows in some sources do not matter if the group totals agree.

Explaining and matching status

For a matching package, a transaction’s matching status is typically matched or unmatched. Known exceptions can be classified as Explained (grouped into explanation categories) when no further action is needed — for example a cancelled order that never reaches the PSP.

You can explain transactions by:

Selecting unmatched items in the UI (Reconciliation › Exceptions) and classifying them (approval may be required).

Applying an Explanation rule so rows that match a pattern become Explained automatically.

Other statuses:

Unknown — initial status until the row participates in a matching run

Not relevant — the row’s source is not in either side of that matching package

After matching, useful properties include:

balance pattern — counts of rows for that transaction id on each side (for example 1–1, 2–1); zeros often signal id mismatches; 2–1 / 1–2 can signal duplicates

balance difference — total amount difference for that transaction id (not split per row)

Example (A vs B)

transactionid	timestamp	source	amount	matching status	balance pattern	balance difference
201	10-1-2023	A	10	Matched	1–1	0
201	20-1-2023	B	10	Matched	1–1	0
202	20-1-2023	A	20	Unmatched	2–2	40
202	20-1-2023	A	30	Unmatched	2–2	40
202	30-1-2023	B	5	Unmatched	2–2	40
202	30-1-2023	B	5	Unmatched	2–2	40
203	30-1-2023	A	10	Matched	1–1	0
203	10-2-2023	B	10	Matched	1–1	0
203	10-2-2023	C	12	Not relevant	Not relevant	Not relevant

Where this lives in the new app

Packages, categories, rules, schedule → Reconciliation › Setup

Day-to-day unmatched work → Reconciliation › Exceptions

Explore matched/unmatched data → Reconciliation Explorer