Reconciliation Rules

Reconciliation rules let you automate the repetitive parts of reconciliation: identifying which transactions and documents belong together, and generating the outgoing documents that post the result back to your ERP. Rules are optional — reconciliation works without them — but they play a crucial role in reducing manual workload for niche scenarios that Atlar's smart matching engine does not capture.

The Two Kinds of Rule

When you create a rule you first choose its Type:

Type	What it does
`Matching rule`	Automatically identifies candidate pairs of transactions and documents using criteria you define. The matches it produces appear as Rule-based suggestions on the `Matches` tab — for example, an incoming bank transaction matched against a customer invoice.
`Creation rule`	Generates outgoing documents directly from a transaction, without pairing it to an existing document — for example, a standalone bank fee that arrives with no corresponding document to match against.

Scope (Rule Target)

Every rule has a Rule target that controls where it applies:

Target	Applies to
`Account`	A single bank account.
`Entity`	An entire GL entity. Entity-level rules are inherited by every account within that entity.

When you view rules for a specific account, any inherited entity-level rules are shown alongside the account's own rules so you can see the full set in effect.

Building a Matching Rule

A matching rule is a set of matching criteria — one row per signal you want to compare between a transaction and a document. Each row has:

A Transaction field — the signal to compare. Options: Amount, Date, Counterparty, Reference.
A comparison control that depends on the field:

Field	Comparison control	How you enter it
`Amount`	`Within Tolerance`	A percentage — the maximum difference allowed between the amounts.
`Date`	`Within Days`	A whole number of days — the maximum gap allowed between the dates.
`Counterparty` / `Reference`	`Operator`	`Equals` (must match exactly) or `Contains` (one value appears within the other).

A Document field, which mirrors the transaction field automatically (amount compares to amount, date to date, and so on).

Add as many criteria rows as you need; a candidate pair must satisfy all rows for the rule to match.

Confidence

Each matching rule carries a Confidence level — Low, Medium, or High — that is applied to the matches it generates. Use higher confidence for tight, unambiguous criteria (for example, exact amount and reference) and lower confidence for looser criteria. Confidence guides how much scrutiny a reviewer applies, and very high-confidence matches may be auto-confirmed (see Reviewing & Confirming Matches).

Require one-to-one matching

The Require one to one matching toggle (matching rules only) enforces that the rule pairs exactly one transaction with one document. Leave it off to allow one-to-many matches (for example, one payment settling several invoices).

Building a Creation Rule

A journal entry rule defines a creation template — the recipe for an outgoing document Atlar produces when a match is posted. Its fields:

Field	Description
`Reference`	Optional. Overrides the bank transaction's reference on the resulting entry. Leave blank to use the transaction reference.
`Balancing line`	The offsetting line. You select its GL Account and, optionally, GL classifications.
`Bank line`	The bank side of the entry. The GL account is derived automatically from the bank account, so you only add optional GL classifications.
`Additional legs`	Extra debit or credit lines. Use Add additional leg; for each leg set its Type (Debit or Credit) and the corresponding Debit GL account / Credit GL account.

Residual templates

A rule can also include Residual templates — outgoing documents generated only when an amount is left over after the match is applied (for example, an underpayment or overpayment). For each residual template you set:

A Trigger — On positive residual or On negative residual.
A Document type — Journal entry, Payment, or Credit memo. For a journal entry, Atlar posts the ledger lines you define; for a payment or credit memo, Atlar sends the document and your ERP calculates the ledger entries.
Optionally, Apply to matched source documents to apply the residual against the documents in the match.

Rule Priority

When several rules could apply, Atlar evaluates them in priority order — higher-priority rules are checked first, and the first rule that produces a match wins. Order your rules so that your most specific, highest-confidence rules run ahead of broader, looser ones.

Built-in Smart Matching vs Your Rules

Alongside the rules you configure, Atlar applies built-in smart matching that looks for agreement across wide-span of data points on the transactions and documents. Smart matching requires no setup and produces the Smart suggestions you see on the Matches tab. Your own rules complement it — use rules to encode patterns specific to your business that smart matching would not infer on its own.