A match type in Oracle Account Reconciliation Cloud Service (ARCS) is the configuration that governs how ARCS’s Transaction Matching module identifies matched transaction pairs between two data sources. When ARCS receives transaction data from Source 1 (for example, the GL bank account ledger entries) and Source 2 (the bank statement transactions), the match type’s rules determine which transactions from Source 1 are matched to which transactions from Source 2 — and how ARCS classifies each match result. A match type specifies: which data fields are compared (amount, date, reference number, description), what tolerances are acceptable (transactions within a defined amount variance are still considered a match), the match basis (one-to-one, many-to-one, many-to-many), and the confidence level assigned to different match result types (automatic match, suggested match, unmatched).
Match Type Structure
| Match Type Element | Options | Finance Use Case |
|---|---|---|
| Matching basis | Amount only; Amount + Date; Amount + Reference; Amount + Description | Bank recon: Amount + Reference; IC recon: Amount + Date + Counterparty |
| Match relationship | 1:1 (one-to-one); 1:M (one-to-many); M:N (many-to-many) | Bank: typically 1:1; ERP payment runs to bank: 1:M (one payment batch, many bank transactions) |
| Tolerance | Absolute amount tolerance (±SAR 0.01); percentage tolerance (±0.01%) | Bank fees rounding differences; FX settlement rounding |
| Auto-match threshold | Confidence score above which ARCS auto-confirms the match without preparer review | Exact amount + exact reference → 100% confidence → auto-match; suggested matches reviewed |
| Unmatched classification | How unmatched items are categorised — timing difference, error, outstanding item | Determines the reconciliation exception categories visible on the ARCS dashboard |
Match Type Design for GCC Bank Reconciliations
Bank reconciliation match types for GCC enterprises must handle several regional payment patterns. SAMA’s Sarie instant payment system produces bank statement entries with different reference formats from traditional SWIFT transfers — the match type’s reference field comparison must accommodate both formats if the bank statement includes both transaction types. ZATCA clearance reference numbers — embedded in bank statement entries for VAT-related payments — can be used as matching fields for reconciling VAT payment transactions between the GL and the bank statement. Match types for Egyptian operations must handle EGP-denominated transactions where bank statement descriptions are in Arabic — the matching logic must compare Arabic-language reference fields correctly, which requires the ARCS data import to preserve UTF-8 Arabic encoding through the entire upload process.
Supported vs Unexplained Match Types
ARCS match types produce two categories of unmatched items: supported (items that are unmatched but have a documented explanation — timing difference, bank error, in-transit item) and unexplained (items for which no explanation has been provided). The reconciliation cannot be submitted for review while unexplained items remain — ensuring that the preparer has addressed every exception before certification. This enforced completeness is the primary control that ARCS adds beyond a spreadsheet-based reconciliation process, where an item might be overlooked without the system preventing submission.
What Goes Wrong in Practice
The most common match type configuration failure is auto-match tolerance set too broadly — where the tolerance allows transactions with significant amount differences to be automatically matched without preparer review. A match type with a SAR 5,000 tolerance on a bank reconciliation might auto-match a SAR 200,000 GL entry to a SAR 195,000 bank statement entry as a “rounding difference” — missing a SAR 5,000 bank error that the preparer should investigate. Auto-match tolerance should be set to the minimum operationally meaningful level, not to the maximum that reduces the volume of items for manual review.
How Loop Wise Solutions Designs Match Types
We design ARCS match types from the existing manual reconciliation methodology — mapping the rules the preparer currently uses to identify matched items in their spreadsheet to the equivalent ARCS match type configuration. The auto-match threshold is set conservatively in the first implementation cycle and adjusted upward only after the initial period’s match results confirm that the auto-matched items are genuinely correct matches, not tolerance-masked exceptions.
Answers before you ask.
A configured set of rules for the Transaction Matching module: which fields are compared between two data sources, what tolerances are permitted, and how each result is classified. It is the specification that tells ARCS how to decide whether transactions from two sources — say bank and ledger — constitute a match.
Because real transactions rarely match to the penny or the exact date across sources. Tolerances let the match type accept small permitted differences — a rounding gap or a one-day timing shift — as a match, while still flagging genuinely unmatched items as exceptions. Set too tight, everything becomes an exception; too loose, and true mismatches slip through.
Directly. Well-designed match types with the right fields and tolerances auto-match the bulk of transactions correctly, leaving only real exceptions for staff to investigate. Poorly designed ones either miss valid matches, creating needless manual work, or over-match, hiding real discrepancies. The configuration is what makes automated matching trustworthy and efficient.
Transaction matching automates the pairing of high-volume items and surfaces exceptions; reconciliation compliance governs the periodic sign-off that the account is supported. Matching reduces the manual work feeding a reconciliation; compliance certifies the outcome. Match types belong to the matching side — they determine how automatically items are paired before the account is signed off.