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. The match type can be contains, equals, starts with, or ends with.

A rule can also name who is on the other side. A money-in rule names a Customer, a money-out rule names a Vendor, and a rule for either direction names a Customer or vendor. The bank feed uses the same labels: a deposit row asks for a customer, a withdrawal row asks for a vendor, and adding a new name from that row creates it as that type, so a new vendor shows up on the Vendors page right away. Both lists are alphabetical and searchable; type a few letters to find a name. When a row has no customer or vendor yet, LedgerHQ guesses one from the bank's merchant name and description. If that name is already on file, the row offers Use it; otherwise it offers Create vendor (or customer) with the name filled in. Nothing is assigned until you click it.

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. If the posted transaction named a customer or vendor, the learned rule keeps that name, and every later transaction the rule matches arrives with it already filled in. A rule you created or edited yourself keeps your own choice.

A QuickBooks history import learns only recurring vendors: a vendor must appear at least twice, most recently within two years of the newest imported transaction. Check numbers and generic descriptions such as Transfer or Deposit never become rules. The rest of the imported history still guides AI and Tally suggestions.

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 has a usable category, including at 1% confidence. Tally also posts researched ordinary best guesses; truly unidentified rows remain in Ready for human input.

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 the best supported categories with their confidence scores.

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 research finds no meaningful clue to a category, LedgerHQ leaves the row uncoded for human input. Uncertainty between plausible categories does not prevent posting the best guess.

New rows without a matching rule also get one automatic research pass shortly after they arrive. That pass happens once per row; the Suggest categories button is how you research older rows or ask again.

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 usable suggestion has at least 1% confidence, 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.

Confidence records the strength of the guess; it is not an approval step. On Core companies, active bank rules post independently of the AI auto-post switch. On Tally companies, rule coding and posting require Tally AI.

Low-confidence Core guesses post too. Manual coding remains available through 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 a truly unidentified row uncoded in Ready with its research 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 best-guess policy 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.