The Transaction Matching export, without fighting the columns
Every match type stores its transactions in tables built from your own attributes, so the columns differ everywhere. Oracle solved its own problem with the Match Type view, and that view is the export door. This page is the route and its three traps.
Note: Transaction Matching, the high-volume half of ARCS, Oracle's reconciliation module, stores every transaction it has paired or failed to pair. This page is the supported route for getting those transactions out to a database you own.
One question this page answers: how do I pull every matched, suggested, and unmatched transaction, with its audit trail, when every match type has different columns? The whole module is mapped on the Account Reconciliation index.
◆ The routes and the traps, the view, the columns, the audit trail, the journals.
| What you need out | The route |
|---|---|
| All transactions of a match type | Query the Match Type view. Per Oracle's doc it holds every transaction across all data sources in the match type, joins to other tables, and queries built on it are portable across environments. This is the population export. |
| The column names | The trap: TM_TRANS_ tables are created per data source at match-type approval, and your attributes define the columns. Oracle's stated method is to read the Match Type view's own SQL to get the names. Do that once per match type, save it beside the query. |
| The audit trail | Matched On dates and job IDs come with the rows; the archive doc confirms archive jobs mark matched transactions by job ID. Export before purging: archived data leaves the app, your star is where it stays queryable. |
| Journal adjustments | A live thread tries to export a day's journal adjustments across many match types in one integration and struggles; per match type is the shape the system gives you. Union them in the warehouse, not in the tool. |
◆ What the star does with it, the June population, and the reports the app cannot hold still.
June in the sixty-entity group: 24,618 transactions across three match types, exported nightly with status, age, and match rule. The star then answers what the app cannot hold still: the aging buckets, the per-rule match rate, and any month, this year or last.
The problem: Every match type has its own bespoke export, and attribute changes break them quietly.
What we build: One export per Match Type view, with the column mappings versioned beside the queries.
What you get: Aging, match rate, and journal evidence become saved queries that survive change.
- Match Type view
- All transactions, all sources, one match type. The export door.
- TM_TRANS_
- Dynamic tables per data source. Columns are your attributes.
- Matched On
- The audit date on every confirmed match. Export it.
- purge
- The app forgetting on purpose. Export first.