Connect bank feeds

Connect A Bank Or Card

Connected feed rows are bank evidence for review. Posting or posting a matched pair records their effect in the ledger. Coding, exclusion, and holds alone do not create a ledger entry.

Open Bank Feeds inside the company workspace and start the bank connection flow. LedgerHQ uses Plaid for bank and card connections. During the Plaid flow, choose the institution, sign in through the secure Plaid experience, and select the accounts you want to connect.

For the full start-to-health workflow, see Connect a bank or credit card.

After the connection returns to LedgerHQ, map each connected bank or card account to the correct LedgerHQ account. This mapping is what lets LedgerHQ show the account as a feed card, create register activity, and keep the feed organized by company account.

If the client needs to connect the bank themselves, use Bank connection texts to send a secure no-login link for a new bank connection or an existing-feed reconnect.

If an account appears connected but does not show as a feed card, look for setup or mapping attention on the Bank Feeds page. The page is designed to distinguish between a true empty state, a loading failure, and a connection that needs setup before it can show normal transaction cards.

If connected Plaid accounts exist but no feed cards are ready, Bank Feeds should show setup or diagnostic attention rather than a plain empty state. That usually means the account needs mapping, the firm needs to disconnect an unwanted connection, import needs to be resumed, or the connection has a health issue that must be resolved before normal review can start.

Each connected account card has a three-dot menu for feed-level actions. Use Change register when the Plaid account is connected but mapped to the wrong LedgerHQ register. This opens the mapping flow so the feed can point to the correct bank or credit card account.

Use Pause import when the account should stay connected to Plaid but stop bringing new activity into the review queue. Pausing is account-specific. It is useful when an account was connected accidentally, is no longer part of the active bookkeeping workflow, or should be temporarily held out of feed review. When an account is paused, the same menu changes to Resume import.

Use Review accounts to disconnect one account while leaving sibling accounts under the same bank login active. Use Disconnect bank feed when every account under that login should stop. The whole connection enters a 72-hour recovery period before LedgerHQ removes it from Plaid and clears its remaining unposted feed-review rows. Posted ledger history stays in LedgerHQ.

Search Account History

Choose an account and a tab, such as Ready, Posted, or All. Search matches transaction descriptions, references, payees, counterparties, and category-account names across the account's stored rows in that tab.

Use From and To for an inclusive bank-date range. Results show the newest rows first, with Previous and Next for pages of up to 75 rows. These controls are separate from the Ask Client workspace.

The select-all checkbox selects eligible rows on the current page. Changing the page or filters clears the selection. Check the selected count before using Post selected, Exclude selected, or Ask Client. For the account-wide action, read Post all coded for one account.

Understand Pending Transactions

Fresh pending Plaid rows appear as Pending at bank. They are visible so the team knows activity is coming. Ordinary unmatched pending rows stay outside coding and posting until settlement or expiry of the hold window. A verified transfer or card-payment pair can post both legs together while pending.

This prevents duplicate or premature accounting. Pending transactions can change description, amount, status, or even disappear before settlement. When a settled transaction arrives, LedgerHQ tries to promote the pending row into the posted feed row instead of creating confusing duplicates.

LedgerHQ also schedules a follow-up pass around the next held pending row's release time. That lets newly postable rows run through rules, history, and AI suggestions without waiting for a later manual refresh or unrelated bank sync. Unverified or unmatched transfer/payment activity can remain held while the other side is found. A verified pair posts together as one accounting movement.

Code And Post Rows

A bank feed row must be assigned to the right accounting treatment before it is posted. Some rows can be coded directly from Bank Feeds. Larger firm-wide work is usually faster in Fast Coding, which shows outstanding feed work across companies.

For the task steps, use Code one bank transaction. Before choosing Post, Post selected, or Post all coded, compare your posting options.

LedgerHQ keeps the work buckets separate. Coded ready to post means the row has an account and can be posted after review. Needs coding means the row is visible but still needs an account, match, or other treatment before it is ready to post. Ordinary held Pending at bank rows are visible context. Posted rows are already ledger activity, and Excluded rows are not active work.

Rows that have enough information can be posted. Posting creates the actual ledger entry and, when appropriate, bank-register activity. After posting, the transaction becomes part of the accounting record and can appear in reports and reconciliation workflows. If Fast Coding is empty, there may still be pending, posted, excluded, or diagnostic rows elsewhere, but those are not rows waiting to be posted from Fast Coding.

Bank Feeds can show two useful coding labels. Rule coded means an active bank rule matched the row and applied the saved account. Suggested means LedgerHQ filled the account from an AI or history-based suggestion. Both labels still deserve review, especially for large or unusual transactions.

Suggestions can use more than exact merchant text. LedgerHQ normalizes common payment-processor wrapper descriptions and can recognize refund history. For example, a positive money-in row from a vendor with strong prior expense history may suggest the same expense account as a likely refund or credit rather than defaulting to revenue.

Active bank rules can post clean matching rows automatically when the row has no warnings and the rule's account still matches the row's account. On Core firms, AI research can also post a suggestion when company AI auto-post is on and the suggestion meets LedgerHQ's fixed 60% confidence floor. Lower-confidence Core suggestions remain for review. On LedgerHQ + Tally firms, Tally AI is the per-company master switch for unattended rule coding, posting, transfer settlement, check application, and client outreach. When it is on, Tally posts a best-fit ordinary account when the researched result is at least 60% confident. Lower-confidence ordinary rows stay uncoded in Ready; an accountant can use Ask Client to move an eligible row to Ask Client. A category a person chose is never overwritten by AI. For the full distinction, see Bank rules and auto-posting.

Understand Quarantined Checks

A settled paper-check withdrawal appears in the separate Checks queue, between Ready and Posted. An accountant may choose one account category there and then use the normal Post action. LedgerHQ records who coded the check and when; no extra rationale is required.

If no accountant codes the check, it remains held. When the bank statement arrives, LedgerHQ can inspect the actual cleared-check image in the statement. A usable match must agree on the register, amount, and check number when one is available. The check remains held when the image is missing, unreadable, ambiguous, or conflicts with the feed row.

After valid image evidence exists, an authorized firm user can also match the check to an existing entry or resolve an image-supported credit-card payment. Selecting a category—manually or from image evidence—returns the row to the normal posting policy; it does not automatically post the check. If the provider mislabeled a row as a paper check, only a firm owner or admin can release it as a misclassification, with a reason and supporting evidence.

Match Transfers And Credit Card Payments

LedgerHQ can recognize internal transfers and credit card payments when it sees opposite signed activity in different registers within a close date window. Accepting a transfer match should create one accounting movement instead of two separate income or expense entries.

When a pair is verified, LedgerHQ can post both legs together even if one or both are pending. It clears the app's holds while retaining the bank's pending evidence. A later settlement updates the existing row rather than posting the movement again. An unmatched or unverified row retains its hold.

When both sides form one unambiguous checking-to-credit-card payment and the evidence bar is met, LedgerHQ can record the transfer automatically as one accounting movement. Generic bank-to-bank transfers still require review. A payment funded by a paper check always stays quarantined until the actual check image supports the transfer.

Credit card payment wording such as "online payment, thank you" may represent a one-sided card payment even when the funding-side bank row is missing. Bank Feeds can preserve that row as banking context, but Fast Coding and Tally's active work queue exclude a counterpart that is waiting on its pending or missing side. It is informational rather than coding work until the transfer/payment treatment becomes actionable.

Disconnect A Feed

Disconnecting one account from Review accounts stops only that account and clears its register mapping. You can restore and remap it from the same dialog.

Disconnecting the whole bank stops every account under that Plaid connection. LedgerHQ keeps the connection recoverable for 72 hours. Restoring any account during that period cancels final removal. If every account remains disabled, LedgerHQ then removes the Plaid connection and clears its remaining unposted review rows. Posted ledger history, completed reconciliations, and statement files stay in LedgerHQ.

Disconnect is intentionally cautious. LedgerHQ should confirm the Plaid removal or receive an expected already-missing response before marking the connection disconnected locally. If disconnect fails, create a support ticket rather than assuming the feed is gone.

See Disconnect or pause a bank feed for the account-level and whole-bank procedures.