Bank rules and auto-posting

Create Rules For Repeating Patterns

A rule saves a match and its account treatment. It can be created by a person or learned from eligible posted activity. An AI suggestion is a researched category for rows without a matching rule. Posting records the transaction in the ledger.

Open Rules from the company workspace when you want LedgerHQ to recognize a repeat pattern. A rule has a name, a priority, a match field, a match type, a match value, and an accounting account. The match field can be description, reference, or merchant/payee. The match type can be contains, equals, starts with, or ends with.

Use rules for stable, high-confidence patterns: payroll providers, loan payments, recurring software subscriptions, merchant processors, bank fees, known insurance drafts, and other descriptions that keep arriving with the same recognizable text. Avoid rules for vague words that could match unrelated transactions.

Higher-priority rules are checked first. This matters when two rules could match the same bank row. Put the more specific rule above the more general rule so a precise match wins.

Rules Learned From Posting

LedgerHQ can learn a company vendor rule after an eligible transaction posts. This applies to bank feeds, registers, Tally, imports, and supported API or assistant posting. The rule uses the category in the posted journal entry and keeps money-in and money-out treatments separate.

Learning needs a stable vendor identity and one clear eligible category. Ambiguous splits, transfers, settlements, and Ask Client holding accounts do not produce an ordinary vendor category rule. Choosing a category without posting is not enough.

A changed treatment can update an untouched automatic rule or create a more specific higher-priority rule while preserving manually maintained rules. A rule-save failure leaves the posted transaction intact; review the result before retrying rule creation. Do not post the transaction again to make a rule.

Backtest A Rule Before You Trust It

You do not have to guess what a rule will do. Before a rule becomes an auto-posting instruction, LedgerHQ backtests the draft against the account's recent history — the last ninety days by default — and reports what it would have caught: how many rows matched, how many of those were already coded, how many were already posted, and which accounts those matches were actually coded to, largest group first.

That backtest is also a safety gate, not just a preview. If the matching rows in history were coded inconsistently — some to fuel, some to meals, some to office supplies — LedgerHQ will not mint an auto-post rule from them, because a rule that would have posted the same pattern several different ways is not a confident instruction. A draft only earns auto-posting when its history agrees on one account. The same check flags an overbroad rule whose match text is catching far more, or more varied, activity than you intended.

Because the backtest reads history you already have, the fastest way to sanity check a new rule is to ask Tally what it would have coded before you turn it on. Review the matched count and the account breakdown: if the breakdown is a single clean account, the rule is safe to auto-post; if it is spread across several accounts, tighten the match text or leave the rule as code-only.

Rules Are Versioned

A rule is not frozen at creation. As a vendor's treatment changes — a new account, a tighter match value, an amount range, a different priority — you edit the same rule instead of deleting it and starting over. LedgerHQ keeps the history for you: every rule has a current version and an immutable snapshot of each earlier version, including who made the change.

Only a real change creates a new version. Saving a rule without changing anything meaningful does not manufacture a history entry, and even retiring or deactivating a rule is recorded as a version rather than erasing it. This means you can evolve a rule confidently, knowing that what it looked like before — and therefore how it coded past transactions — is preserved and attributable.

What Rule Coding Does

When an active rule matches an uncoded, unposted, non-excluded bank feed row, LedgerHQ applies the rule's account and related coding fields to the row. The row can then show as Rule coded in Bank Feeds. That label means the row was pre-coded by an active rule and is ready for the normal posting checks.

Rule coding does not overwrite a human choice. If a user manually recodes a row away from the rule's account, the manual decision wins. Rules are meant to handle repetitive untouched rows, not fight user review.

Rules also apply to rows that arrived before the rule was created. If you add or edit a rule after feed activity has already synced, LedgerHQ can still code matching uncoded rows that remain unposted and eligible.

How Rule Auto-Posting Works

Active rules can post matching bank feed rows automatically when the row is coded to the same account as the matching rule and has no posting warnings. Rules are treated as a firm instruction: if the active rule confidently matches a clean row, LedgerHQ can post it through the same posting path a user would use. Core AI suggestions use the same atomic accounting posting path when company AI auto-post is on and the suggestion meets LedgerHQ's fixed 60% confidence floor. Tally posts researched ordinary best-fit rows at the same floor and leaves lower-confidence rows uncoded in Ready.

Rule auto-posting still respects safety gates. LedgerHQ does not auto-post rows that are pending at the bank, excluded, already posted, missing an account, zero-dollar, suspected duplicates, suspected transfers, removed by the provider, or otherwise carrying warnings that require human confirmation.

How AI Suggestions Work

Rows without matching rules can still get help from LedgerHQ's suggestion system. Bank Feeds can show Suggest categories for the currently visible uncoded rows. LedgerHQ reviews transaction details, available history, and the company chart of accounts, then returns only suggestions it considers confident enough to show.

When a suggestion is applied, the row can show as Suggested. That means the account was filled from a suggestion, not from a bank rule. Users can change the account before posting. Suggested rows are still reviewable; they are not automatically correct just because they are convenient.

If no confident suggestion is found, LedgerHQ leaves the row uncoded. That is intentional. It is better to leave a row for human review than to create a misleading category.

How Core AI Posting Works

On Core firms, AI research can suggest or pre-code an account. When AI auto-post is on for the company and a suggestion meets LedgerHQ's fixed 60% confidence floor, it can post automatically through the normal accounting path. New companies start with AI auto-post off. Turn it on from the Bank Feeds page header — it stays visible even when there are no ready-to-post rows.

The 60% confidence floor is fixed by LedgerHQ for every company. On Core companies, active bank rules post independently of the AI auto-post switch. On Tally companies, rule coding and posting require Tally AI.

Lower-confidence Core suggestions remain for review and can be posted with Post all coded or a row-level posting action. If a person has selected a different category, that human choice wins and AI does not overwrite it. A successful Core AI post also creates a rule so the confirmed vendor treatment becomes a repeatable firm instruction.

How Tally AI Works

On LedgerHQ + Tally firms, the firm's books and each managed company have a separate Tally AI activation switch. New workspaces start with Tally AI off. When the firm is not paused and Tally AI is on for the selected workspace, Tally researches clean ordinary rows and either:

• posts a best-fit active revenue or expense account for that exact row, or
• leaves an unresolved or below-60% row uncoded in Ready with its suggestion and rationale. An accountant can then code it or use Ask Client to post an eligible row to the bound Ask Client holding account by direction.

Already-coded active accounts post as-is. Special rows, transfers, card payments, quarantined checks, warnings, pending rows, and locked periods stay in their exact workflows. Eligible best-fit and already-coded posts can learn a narrow vendor rule; Ask Client posts do not. Tally uses the same fixed 60% confidence floor as Core AI posting. When Tally AI is off, bank sync, matching, evidence, and research continue, while rule coding/posting, transfer settlement, check application, and client outreach wait for an explicit action.

What Users Should Review

Review the first few runs of any new rule. Check whether the match text is too broad, whether the account is correct, and whether any transactions should be handled as transfers, credit card payments, loan movements, owner activity, or matches to existing register entries instead of simple expense or income coding.

For AI suggestions, review the payee, description, amount, suggested account, and any warning evidence. Use Post all coded only when the visible coded rows are routine and warning-free. If a row looks unusual, leave it unposted and ask Tally or create a support ticket with the company name, transaction date, amount, description, and what looks wrong.