Transaction Matching Rules, Explained
A simple guide to how NewLedger ranks imported bank transactions and what each matching factor means.
When you import bank transactions, NewLedger tries to surface the most likely accounting match first.
That might be:
- an invoice-related record
- a bill
- an expense
- a journal-linked record
- a grouped match across several entries
Transaction Matching Rules tell NewLedger how cautious or flexible that ranking should be.
This article explains the actual rule settings you see in NewLedger, so you can understand what each one changes without needing to read the raw JSON.
What Is A Transaction Matching Rule?
A transaction matching rule is a saved matching profile.
It does not change your accounting records by itself.
It changes how NewLedger evaluates and ranks possible matches by adjusting things like:
- how strict amount comparison should be
- how far apart dates can be
- how important references are
- how flexible description matching should be
- whether grouped matching should be considered
- how much counterparty linkage should matter
The Business Rules You Actually Set
Most users work with the Business Rules section, not the advanced JSON.
These are the main controls in NewLedger today:
| Rule setting | What it means |
|---|---|
| Risk level | How cautious or fast the matching behavior should feel |
| Automation level | How assertively NewLedger should treat stronger matches in the ranking flow |
| Amount strictness | How exact the amount comparison should be |
| Date tolerance | How many days apart a transaction and candidate record can be |
| Reference importance | How heavily reference numbers should influence matching |
| Description flexibility | How strict or flexible text matching should be |
| Grouping | Whether grouped deposits or split-style matching should be considered |
| Counterparty | How strongly linked customer or vendor information should matter |
If you never open the advanced JSON view, these are the settings that matter most.
What Each Business Rule Does
Risk level
| Option | Meaning |
|---|---|
| Conservative | Stricter matching thresholds |
| Balanced | Normal day-to-day matching behavior |
| Fast | More permissive scoring so likely matches surface more quickly |
Automation level
| Option | Meaning |
|---|---|
| Suggest only | Show candidates for review |
| Auto high confidence | Lean more strongly toward high-confidence candidates |
| Auto with exception review | Favor operational matching flows while still leaving room for review |
Amount strictness
| Option | Meaning |
|---|---|
| Exact | Very tight amount matching |
| Rounding | Allows small real-world variation |
| Fees | More tolerant for fee-heavy or slightly offset transactions |
Date tolerance
| Option | Meaning |
|---|---|
| Same day | Very strict date matching |
| Three days | Good default for most workflows |
| Seven days | More flexible for slower settlement timing |
Reference importance
| Option | Meaning |
|---|---|
| Required | References matter a lot |
| Preferred | References help, but are not mandatory |
| Optional | Matching should not depend heavily on references |
Description flexibility
| Option | Meaning |
|---|---|
| Strict | Description text must line up more closely |
| Balanced | Normal text matching |
| Flexible | Description text can be looser when other signals help |
Grouping
| Option | Meaning |
|---|---|
| Off | Do not prioritize grouped matching behavior |
| Deposits | Allow grouped deposit-style matching |
| Splits | Lean more into split or grouped selection behavior |
Counterparty
| Option | Meaning |
|---|---|
| Required | Linked people information matters strongly |
| Preferred | Counterparty linkage helps when available |
| Optional | Matching should not depend much on linked people data |
A Simple Example
Here is an easy-to-read example of a business-friendly rule:
| Setting | Example value | Meaning |
|---|---|---|
| Risk level | Conservative | Keep matching tighter |
| Amount strictness | Rounding | Allow small normal differences |
| Date tolerance | Three days | Accept nearby settlement dates |
| Reference importance | Required | Reference clues matter a lot |
| Description flexibility | Balanced | Use description as support, not the main driver |
| Grouping | Deposits | Allow grouped deposit-style matching |
| Counterparty | Preferred | Linked people data helps when present |
This kind of rule fits teams that want good invoice-style matching without making the engine too aggressive.
What The Advanced Numbers Mean
If you open the advanced JSON view, you will see three technical groups:
| Section | What it controls |
|---|---|
thresholds | Cutoffs, tolerances, and scoring minimums |
boosts | Extra scoring added when a signal matches well |
signals | Whether a signal is enabled at all |
These advanced values are real, but they are not the best starting point for most users.
Thresholds
Thresholds control things like:
- minimum score for high-confidence results
- minimum score for medium-confidence results
- amount tolerance
- date window in days
- description overlap percentage
Example:
If the date window is 3, NewLedger can treat records within three days as aligned.
If the amount tolerance is tighter, a transaction for $100.00 may not match a record for $92.95.
Boosts
Boosts add extra score when a signal matches well.
Common examples in NewLedger include:
- amount aligned
- date aligned
- description aligned
- reference aligned
- reference present
- counterparty linked
- grouped selection
- currency aligned
Boosts help stronger candidates rise above weaker ones.
Signals
Signals are on/off controls for the engine.
For example, a rule can decide whether NewLedger should consider:
- amount alignment
- date alignment
- description alignment
- reference alignment
- reference presence
- counterparty linkage
- grouped selection
- currency alignment
If a signal is off, that clue is no longer part of the ranking logic for that rule.
Why Different Businesses Need Different Rules
Not every business reconciles transactions the same way.
For example:
- a company receiving invoice payments may care a lot about references
- an expense-heavy account may care more about description and counterparty behavior
- a finance team doing tighter review may prefer conservative thresholds
- an operations-heavy team may prefer faster matching with exception review
That is why NewLedger supports both system rules and custom rules.
A Good Rule Name Should Be Simple
Rule names should explain the business intent, not the technical setup.
Good examples:
- Invoice First
- Conservative Matching
- Expense Review Flow
- Daily Banking Review
If a teammate can understand the purpose from the name alone, the rule is doing its job.
Best Practices For Beginners
| Recommendation | Why it helps |
|---|---|
| Start with a built-in rule | Faster and easier than building from scratch |
| Use the Business Rules section first | It matches how the product is designed for normal users |
| Use one default rule | Keeps your team consistent |
| Create custom rules only when needed | Avoids confusion |
| Use plain names and descriptions | Makes rule selection easier |
| Open advanced JSON only for fine-tuning | Better for power users than first-time setup |
Final Takeaway
Transaction Matching Rules are there to help NewLedger rank likely matches in a way that fits your workflow.
For most teams, the simplest approach is best:
- start with a built-in rule
- adjust the business-rule settings
- set one clear default
- use advanced JSON only when you need deeper control
That usually gives the best result: cleaner matching, less manual review, and more confidence during reconciliation.
Explore accounting workflows with NewLedger