reconify.yaml describes two things: where your files are and how to parse them (sources), and which sources to compare and under what rules (pairs). Once you can read those two blocks, you can read any Reconify config.
Sources
A source names one family of input files and tells Reconify how to parse them.file_pattern is what reconcile uses to find files when you don’t pass --left-file or --right-file explicitly. The parser block controls how each row becomes a transaction: see Transactions for the fields it produces.
Pairs
A pair tells Reconify which two sources to compare and how strict to be about it.date_window and amount_tolerance_minor set how close a same-reference row on each side has to be to count as matched rather than amount_diff or timing_diff. name_mode: tokens turns on name-based matching for rows that reference matching couldn’t resolve.
The right source is indexed first, and that index is what bounds peak memory for the run. For large files, prefer the smaller or more index-friendly file as the right side.
See Handle large files for what “index-friendly” means at scale.
Multiple pairs in one config
A singlereconify.yaml can define more than one pair, each with its own tolerances:
--pair:
One left, several counterparts (rights)
Some workflows need one left source reconciled against several counterpart sources in a fixed order, for example a ledger that might settle through either of two PSPs. Use rights instead of right:
right and rights are mutually exclusive: set exactly one. Passes run in the order listed in rights, and each counterpart only sees the left rows still unmatched from the previous pass, so right_source gets the full left set and another_source only sees what right_source didn’t consume.
If two counterparts could both match the same left row, the earlier one in rights wins. Order here is a configuration decision, not a formality: swapping the list changes which counterpart gets first claim on ambiguous rows.
A rights pair carries some caveats a single-right pair doesn’t:
--auditisn’t supported for multi-counterpart runs yet.name_mode: tokensisn’t supported in streaming multi-counterpart mode; omit it forrightspairs.--right-filedoesn’t apply, since each counterpart resolves its own file through its source’sfile_pattern.
Which side is left?
Left and right aren’t interchangeable. The right source gets indexed, which is where memory cost concentrates, so put the larger or harder-to-index file on the left when you have a choice. It also determines which unmatched bucket a row lands in: a row present only in the left source comes back asunmatched_left, and a row present only in the right source comes back as unmatched_right. Pick left and right so those two buckets mean something to whoever reads the results, not just so the run finishes fast.