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.

When Activity Updates

Connected banks update once a day, between 2 and 7 a.m. Eastern, so each morning shows the activity your bank had made available overnight. A newly connected or reconnected bank checks every few minutes until its transactions load, and a manual update request checks right away. Bank availability still determines when transactions arrive; a successful check does not mean that bookkeeping is finished.

At 4 p.m. Eastern, LedgerHQ also checks every healthy connected bank. A bank whose last successful update is more than a day old, and that has no sign-in problem, gets one extra refresh request that afternoon.

Each account card shows Transactions through, the date of the newest transaction the bank has sent, and Bank checked, when Plaid last reached the bank. A bank that needs the owner to sign in again shows Reconnect. A register with imported history but no bank connection shows Not connected where the bank balance would be.

If a card says most of its recent charges also appear in another register, the bank is likely reporting the same charges twice, such as an old card number or a card program's billing account. Keep one of the two feeds and use Pause import on the other.

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 Upload CSV to bring in a bank's CSV, OFX, or QFX download, for any dates. Uploaded rows join the same list as bank rows and are handled the same way. Add feed creates a card for an account with no bank connection, and Hide feed takes a card off the page. See Upload bank or card activity from a CSV.

Some banks share an account's balance with LedgerHQ but not its transactions. Chase business lines of credit and investment accounts are common examples. With nothing to review, those accounts stay off Bank Feeds. Once you upload a CSV for one, its card shows a Balance only pill, and the rows join the feed like any other.

Loans and lines of credit get a loan register on a liability account. A payment you post from checking also appears in the loan's register, so you can reconcile the loan against its statement balance owed.

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. The card stays as a files-only feed with its waiting rows, and 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.

To name the payee on many rows at once, select them, pick a name in the Customer / vendor box on the selection bar, and choose Set on N. The customer/vendor stays editable on posted rows too, because changing it posts nothing.

Rows That May Already Be In The Register

Bank Feeds shows every transaction the bank delivers, including history requested when the account was connected. A row that looks like activity already in the register carries a May be in register label. It is not hidden, and automatic posting skips it until someone decides. Post it if it is new, or exclude it if it is a duplicate.

To clear many at once, turn on the May be in register filter, choose Select all matching rows to select every matching row across pages, and use Exclude selected. Each excluded row is recorded and can be restored from Excluded.

Imported history and bank feeds share each register. When a QuickBooks import, statement import, or other register history import covers dates where bank-feed transactions are already posted, LedgerHQ refuses the import and names the register, count, and dates. Undo those transactions from Posted, then import again. Unposted feed rows in imported dates stay visible with the May be in register label.

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 the bank settles or removes them. Age alone does not release bank-reported pending activity. 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.

A settled credit card payment with only one side in LedgerHQ waits in Pending so nobody posts half of it. As soon as the other side arrives, both rows move to Ready together as one transfer. If no match arrives within 7 days, the row moves to Ready with a No matching payment found label. This hold is separate from bank-reported pending activity, which has no age-based release. Every row is in exactly one tab: Ready, Pending, Posted, or Excluded.

When the bank withdraws a transaction, LedgerHQ excludes the row with an audit entry. A withdrawn row that could not be excluded, for example because it was already posted, stays in Ready with a removed by bank pill and is never treated as pending. Automation skips it and reconciliation will not use it until a person reviews it.

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 there is a usable best-guess category, including at 1% confidence. Truly unidentified rows remain for human input. 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 the best-fit ordinary account even at low confidence. Only ordinary rows with no meaningful category evidence 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.

When Tally AI is off for a LedgerHQ + Tally company, Ready shows Tally is waiting for Tally AI to be turned on for this company. Nothing posts automatically until then. Tally can still research and suggest categories. Turn on Tally AI for the company to let her post.

Review Checks Awaiting Evidence

The Checks queue tracks unresolved check evidence. Eligible settled checks can already be posted to the Checks holding account while awaiting an image. Review the linked journal before creating any new posting. Valid image evidence can correct the holding treatment or match an existing payment; missing or conflicting evidence stays for review. See Review checks awaiting 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. Each Bank Feeds card stays as a files-only card, and its waiting rows stay in Ready until you post or exclude them. 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.