Banking

Banking is the daily-life half of bookkeeping — moving money in and out of bank accounts, reconciling against statements, transferring between accounts, and writing checks. Most of the transaction types in Solid touch a bank account on at least one side; this page covers the operations specific to that touch point.

If you haven't read General Ledger yet, the underlying model (debits, credits, transaction types) is described there.

Bank accounts in the chart

Bank accounts are accounts of type CASH (Cash and Bank). The is_cash_type flag on the account-type definition is what identifies them; reports that filter to "cash accounts" use this flag rather than name matching, so you can call your bank account whatever you want.

Most files have at least:

• Operating Checking — the main day-to-day account
• Savings or Money Market — where reserves live
• Credit Card accounts (account type LIABILITY, but treated similarly for reconciliation)

The model treats credit-card accounts as cash-equivalent for reconciliation purposes — you reconcile a credit-card statement the same way you reconcile a bank statement. The GL effect is just opposite-direction.

Checks

Writing a check posts a journal entry of transaction_type = 'check':

DR  Expense (or Asset, per line)
CR  Bank

Common cases: paying a vendor on the spot (no bill recorded first), reimbursing an employee, paying rent, sending an owner draw. If you have a bill recorded already, use Pay Bill instead — that hits the payment_applications table to clear the AP balance, which a Check entry doesn't.

The check's reference_number field stores the check number. Solid auto-increments from the next available number in the configured sequence; you can override per check (useful when starting from an existing checkbook with checks already used).

Deposits

A deposit posts a journal entry of transaction_type = 'deposit':

DR  Bank
CR  Income (or other source per line)

Use cases:

• A direct cash sale you didn't issue an invoice for (cash from a market stall, a small consulting check)
• Interest earned on a bank account (DR Bank / CR Interest Income)
• A refund or reimbursement that came in as cash, not against a bill

Deposits with multiple lines let you split one deposit slip into multiple income categories — a $1,200 deposit that was $800 service + $400 product, posted as two lines.

For payments from customers against existing invoices, use Receive Payment instead — that clears the customer's AR balance through the payment_applications model.

Transfers

A transfer is a journal entry of transaction_type = 'transfer' between two accounts you own:

DR  Destination Bank
CR  Source Bank

Move money from Operating Checking to Savings; pay down a credit card from checking; transfer between currency accounts. Transfers don't touch revenue or expense — both sides of the entry are balance-sheet accounts.

If you transfer between accounts in different currencies, Solid captures the exchange rate at the transfer date and computes any FX gain/loss the same way as on multi-currency invoices. See General Ledger → Multi-currency.

Undeposited Funds

The Undeposited Funds account is an asset account that sits between receiving a payment and making a deposit at the bank. Use it when you collect multiple customer payments throughout the day and deposit them as one batch.

The flow:

1. Receive Payment posts to Undeposited Funds, not directly to the bank:

   DR  Undeposited Funds
   CR  Accounts Receivable
   

2. At the end of the day (or whenever you batch), Make Deposit moves the lump from Undeposited Funds to the bank:

   DR  Bank
   CR  Undeposited Funds
   

This way, the deposit on your bank statement matches one entry on Solid (the Make Deposit), making reconciliation clean. Without Undeposited Funds, ten small Receive Payments would have to match against one big bank deposit — frustrating to reconcile.

For digital payments where each transaction lands separately (Stripe, PayPal), skip Undeposited Funds and post Receive Payment straight to the bank account — each digital deposit matches one entry directly.

Reconciliation

Reconciliation is the operation that proves the file matches the bank: every transaction on your statement matches one in Solid, every transaction in Solid is on the statement (or known to be in transit), and the ending balances agree.

The reconciliation flow

1. Open the bank account in Solid and choose Reconcile
2. Enter the statement's beginning balance (Solid pre-fills with the last reconciled balance) and ending balance
3. Check off every transaction on your statement, line by line, against Solid's list of unreconciled entries
4. The difference shown live should approach zero as you check items
5. When the difference is zero, Complete Reconciliation locks those transactions as reconciled and stamps them with the statement date

When the difference doesn't reach zero

The reconciliation flow has a force-complete option that posts a balancing adjustment entry to a configured Reconciliation Discrepancy expense account. Use it sparingly — every force-complete is logged in the audit trail and accountants treat them as flags during review.

The reconciliation history

Every completed reconciliation is stored: statement date, beginning balance, ending balance, who reconciled, and which transactions were included. From the bank account's view, Reconciliation History lists past reconciliations and lets you reopen one to investigate or correct.

Re-opening a reconciliation un-flags the included transactions (they go back to "unreconciled") so you can change them. Done sparingly — the entire point of reconciliation is to lock down what's been verified, and reopening one breaks that lock.

Bank Feeds

Bank Feeds connect Solid Accounting to your bank or credit card via a third-party data aggregator, automating the otherwise-manual download of transactions. When connected, transactions appear in Solid as the bank reports them, ready to match against existing entries or post as new ones.

How it works

1. Connect a bank via the connector dialog. Solid uses Plaid (or another aggregator we support) to authenticate against your bank — credentials never touch Solid's infrastructure
2. Select which accounts to sync (most banks have multiple accounts under one login)
3. Solid pulls the transaction history for the period you specify
4. Each pulled transaction shows in a review queue with three actions:
   • Match to an existing Solid entry (e.g., a Check you already wrote)
   • Create new entry from the pulled data
   • Ignore (typically for bank-internal transfers Solid already tracks via Transfer entries)
5. After review, processed transactions become regular journal entries in Solid — same as if you'd entered them manually

Sync behavior

The aggregator pulls new transactions on a schedule (typically daily) — Solid surfaces them in the review queue automatically. You don't have to manually trigger the pull, but a manual Sync Now button is available when you want to refresh.

What it doesn't do

Bank Feeds doesn't categorize transactions for you (some products try; the suggestions are usually wrong enough that they create more cleanup than savings). You match each pulled transaction against an existing entry or assign it an account explicitly. The trade is between speed of input and accuracy of categorization — Solid favors accuracy and your one-time setup of recurring categorizations carries forward.

Cost

Bank Feeds is a paid add-on at $8/mo or $79/yr for two connections. This is a separate fee because the aggregator (Plaid, et al.) charges Solid per active connection per month — pass-through pricing rather than baking it into the base license. Each connection is one bank login (one connection can sync many accounts under that login).

Common gotchas

Reconciliation difference of exactly the bank fee. The bank charged a service fee that's on the statement but not in Solid. Add a Check (or a deposit-with-negative-line) for the fee, posting to a Bank Service Charges account, then complete the reconciliation.

Two transactions with the same amount and date — Solid matched the wrong one. Bank Feeds' matcher uses amount + date as a fast first pass. If two transactions for the same amount post on the same day, the matcher may pick the wrong one. The review queue lets you correct the match before processing.

Voided check still shows on reconciliation. Voids leave the original entry in the file (with a reversing entry), so both the original and the reverse appear unreconciled — net zero. Check off both at once on the statement that closed after the void, or use Force Complete.

Bank statement balance doesn't equal Solid's bank account balance even after a clean reconciliation. This is normal if you have outstanding (uncashed) checks or deposits in transit — they're in Solid but not yet on the statement. The reconciliation report shows the gap explicitly.

Reconnecting a Bank Feed asks me to re-authenticate every time. Some banks expire the access token after a fixed period (a week, a month) for security. If you find yourself reconnecting weekly, that's the bank's policy, not Solid's — there's no fix from our side.

Cross-references

• General Ledger → cash-vs-accrual for how reports treat the timing of cash movements
• Accounts Receivable → Undeposited Funds for the AR side of the batch-deposit flow
• Accounts Payable → Pay Bill for the bill-clearing path that produces a bank-account credit