Banking & Reconciliation
Manage bank accounts, Plaid-connected bank activity, and reconciliation.
Bank Accounts
Create bank accounts linked to your chart of accounts. Each account owns its own bank transactions and reconciliation workflow.
Fields
| Field | Description |
|---|---|
| Account Name | Display name (e.g., "Business Checking") |
| Account Number | Masked number for display |
| Bank Name | Name of the bank |
| Currency | Account currency |
| Country | Country or region of the account |
| Account Type | Checking, savings, credit card, cash, loan, investment, or other |
| Accent Color | Visual identity used across the banking UI |
| GL Account | Chart of accounts link |
Bank Activity
Bank and card activity arrives through Plaid-connected feeds, which sync internally on a webhook-driven basis. There is no public "import rows" endpoint. Partner posting endpoints also create bank-register rows automatically when a purchase, deposit, transfer, or bill payment uses a bank-linked chart account.
Synced rows enter as bank transactions with sourceType: plaid_bank_feed and
store provenance including the external transaction ID, sync batch, and raw
payload metadata.
The supported flow is:
- Connect a bank or card through Plaid and map it to a bank account
- Let Plaid-connected feeds sync activity automatically
- Hold fresh pending rows until they settle or age past the pending window
- Review, categorize, match, or post eligible transactions
- Reclassify account/contact/tax fields when posted activity needs cleanup
- Reconcile or exclude posted register activity
- Pull financial packet JSON for report rendering
Pending Plaid rows are visible evidence, not posting work. They are held out of coding, rules, AI suggestions, matching, posting, and reconciliation until settled or aged into the normal workflow. Internal transfer and credit card payment matching can claim both sides of a movement atomically when the pair is clear.
Relevant routes:
| Method | Path | Purpose |
|---|---|---|
GET | /api/v1/bank-feeds | List connected bank feeds |
GET | /api/v1/bank-feeds/health | Per-connection and per-account Plaid feed health |
POST | /api/v1/purchases | Post spend activity and create bank-register activity when bank-linked |
POST | /api/v1/deposits | Post received money and create bank-register activity when bank-linked |
POST | /api/v1/transfers | Post movement between two balance-sheet accounts |
POST | /api/v1/bill-payments | Post a bill payment from a bank-linked or other balance-sheet account |
Reconciliation
Reconciliation confirms that a bank or credit card register agrees with the statement ending balance for a period. The current workflow uses statement end date, prior completed ending balance, ending balance, and cleared posted rows.
Transaction Statuses
- Unreconciled — Not yet matched
- Reconciled — Matched to a journal entry
- Excluded — Intentionally ignored (e.g., transfers between own accounts)
Reconciliation Workflow
- Prepare the account and statement period.
- Create or resume a reconciliation session.
- Enter the correct signed statement balance.
- Clear the transactions that appear on the statement.
- Edit or cancel in-progress setup if the session was started incorrectly.
- Finish at zero difference, or intentionally create a Reconciliation Entry for an accepted variance.
For liability-style registers such as credit cards and loans, positive institution balance-due amounts usually become negative LedgerHQ balances.
Statements And Coverage
Statement PDFs and uploads live in the Statements workspace. LedgerHQ can store Plaid-provided statements, firm uploads, and client uploads. OCR/extraction reads structured statement data when available, and statement coverage policies track which account/month periods are verified, received unverified, mismatched, waived, or missing.
Statements support reconciliation and close, but they are not the reconciliation itself. A verified statement period means the firm has statement evidence. It does not mean the register is already reconciled.