The goal of setting up the Actuals Platform for a company is to determine if all transactions are recorded in several main systems in a consistent way. Transactions can be anything that has properties timestamp, transactionid and amount. This means that transactions on the platform are not limited to ecommerce orders, but can also include supplier invoices, accounting statements, hours logs and any custom entity that comes to mind. The Actuals Platform provides many options to generate and create these transactions with the right properties for comparing and reporting.
These systems that these transactions belong to are shown as sources in the platform. Data for these sources can be collected in several ways
- Actuals connects with an external system to collect the data
- The company sends the data to the Actuals platform directly (API)
- Files containing the data are provided to the Actuals SFTP server
- Files are uploaded to the platform directly using the user interface.
The best option for a source depends on the type of connection and the infrastructure at a company. The Integrations section provides details on the many possibilities.
Matching
A matching package defines an expected relation between a set of sources and another set of sources on a transactional level. The Actuals Platform aims at managing the exceptions to this expected relation. An example of a matching package is a comparison of order data with Payment Service Provider (PSP) data. The expectation is that every order stored in the order system is paid for with the exact same amount in the PSP. The Actuals Platform performs the matching of the transactions in both sources and reports the overall status for this matching package. Additionally, the impact of the exceptions is reported and individual transactions that don’t match are visible in the Platform.
When defining the sources to compare in a matching package, multiple sources can be selected on both sides. For instance, a matching package can be created that compares the transactions of 3 sources with the data of 4 other sources. The matching process consists of calculating the total amount per transactionid in the first set of sources as well as the total in the second set of sources. This means that if for a transactionid multiple rows are available in the Platform, the amount is summed and compared with the sum of the transactions in the second set of sources. If those totals are the same, the transactions match.
Example
Assume we have the following transactions and a matching package that compares the 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 |
In this case all 9 transactions (transactions are rows of data in the Actuals Platform!) match. For transactionid 123 the total amount of 10 is the same in both A and C. For transactionid 124 the total amount in the first group (A and B) is 20+30=50. The total amount in the second group (C and D) is 50. As these amounts are the same all 4 transactions for 124 match. For transactionid 125 the total amount is 10 in both groups and hence these 3 transactions also match. Note that the absence of transactions in sources B and C is irrelevant to the total sum.
Explaining and other matching details
When transactions are matched, the outcome is either matched or unmatched as matching status (for that matching package). The Actuals Platform allows additional processing on the transactions to group and report the unmatched transactions. This is useful in cases where there is a known reason for the transactions to not match and no additional action is required. An example of such a case is a cancelled order. A transaction in one source can have a (non zero) amount but additional property that the status is cancelled. In the other source the transaction is not available because when cancelled, no payment is made for example. In this situation it is useful to classify the transaction as Explained as this is a known exception to the matching process and no further action is required. Explained transactions are always grouped into categories so be able to report on the type of exceptions clearly.
The matching status of a transaction can be changed to Explained in two ways. Firstly, it is possible through the user interface to select unmatched transactions and classify the transaction as explained. Depending on the setup, an approval of a colleague is required to make this classification final. The second way of changing the matching status to Explained is by applying an Explanation rule. The platform allows the setup of rules which result in transactions being classified as Explained when they meet a certain pattern. This is a very effective way of explaining a lot of transactions at once as users don’t have to go through each transaction individually.
Apart from Matched, Explained and Unmatched a transaction can have a matching status of Unknown or Not relevant. Unknown is the initial status that is assigned when a transaction is created and the transaction keeps that status until the transaction is part of a matching run. Transactions are assigned the status Not relevant when the source the transaction is part of if not in one of the groups of sources defined for a matching package. If a matching package compares source A with source B then all transactions in source C get the matching status Not relevant (as the transaction is not relevant for that matching package).
Apart from the matching status, some other properties are available for a transaction when the matching is complete. The balancepattern is defined as the number of rows for that transactionid in the first set of sources followed by the number of transactions in the second set of sources. Balancepatterns can be quite useful in understanding common patterns as they indicate mismatch of ids (then the pattern contains a 0) or showing duplicate transactions (either 2–1 pattern or 1–2 pattern). The balancedifference property is defined as the total difference of matching for the transactionid. Note that this is the total difference, not spread out per transaction (row)
Example
To illustrate these additional properties, below is a set of transactions and the values of the matching properties for the matching package for source A with source B
transactionid | timestamp | source | amount | matchingstatus | balancepattern | balancedifference |
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 |