Connect bank feeds

Bank Feeds is where LedgerHQ shows Plaid-connected bank and credit card activity for the active company. A connected feed brings transactions into a review queue. Those rows do not affect the ledger just because they synced. They need to be coded, matched, posted, excluded, or held until they are ready.

This distinction is important. Bank feed activity is provider evidence and work to be reviewed. Posted ledger entries are accounting records. LedgerHQ keeps those concepts separate so users can see what the bank sent before deciding how it should affect the books.

Connect A Bank Or Card

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.

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, import needs to be resumed, or the connection has a health issue that must be resolved before normal review can start.

Use The Account Menu

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 Disconnect bank feed only when the institution connection should be removed from Plaid. Disconnecting stops Plaid access and future syncing for the bank connection, clears unposted feed-review rows for that connection, and keeps posted ledger history in LedgerHQ.

Understand Pending Transactions

Fresh pending Plaid rows appear as Pending at bank. They are visible so the team knows activity is coming, but they are intentionally held out of coding, rules, AI suggestions, posting, matching, and reconciliation until the bank settles them or they age past the hold window.

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. If one side of a transfer or credit card payment pair is still pending, the matched settled side can also stay held so the pair is not posted in pieces.

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.

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. Pending at bank is visible context only. 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 also post clean matching rows automatically when the row has no warnings and the rule's account still matches the row's account. The AI auto-post switch is separate: it controls high-confidence AI researched rows, not active bank rules. 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.

If only one side is settled and the other side is still pending, LedgerHQ holds the pair back from normal posting. This is intentional. It is safer to wait for both sides to settle than to create an incomplete transfer that has to be unwound later.

When both settled 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 a bank feed removes the Plaid Item connection for that institution. LedgerHQ keeps posted ledger history and raw evidence, but clears unposted review rows from active queues for that Plaid Item so old disconnected feed rows do not keep appearing as current work.

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.