The Banking hub - and the maker-checker rule behind three screens
The hub is a launcher, not a report of its own - every number on it (total balance, unmatched count, open deposits, pending transfers) is a live figure pulled fresh each time, plus a warning if any account hasn’t had a statement imported in 30+ days. Three screens further down - Fund Transfers, Bank Adjustments (via Bank Transactions), and Petty Cash Replenishment - share one identical rule worth knowing up front: whoever creates the request can reject it, but can never be the one who approves it. Below a configured amount they post immediately; at or above it, they wait for a different person to sign off.
Bank Accounts
Each Bank Account you add - bank, cash drawer, credit card, wallet, or payment gateway - automatically gets its own General Ledger account behind the scenes; you never have to pick one manually. An opening balance posts a real journal entry, once, the same way a Customer’s or Vendor’s does. Archiving an account archives its linked GL account too, and is blocked if that GL account is still doing system work elsewhere.
Bank Transactions - the actual reconciliation workspace
This is where a bank statement (imported as CSV/Excel, pasted, or as a real bank format like MT940, BAI2, OFX/QFX, or camt.053) turns into cleared-up books, one line at a time. Every line gets exactly one outcome: Categorize posts a brand-new entry (a bank fee, interest, or other charge you haven’t recorded yet); Match links the line to a Payment, Vendor Payment, Deposit, or Refund that already posted, with no new entry; Ignore records that the line has no financial effect, with a reason required. Re-importing the same file silently skips rows you’ve already brought in - it will never duplicate a line.
Amount doesn’t match? Match + write-off handles both at once
If a transaction almost matches an existing payment but the amount is slightly off, "Match + write-off" posts the small difference as an adjustment and completes the match in a single action - you don’t have to fix the payment first. "Run rules" applies your saved Matching Rules automatically to everything still unmatched.
Bank Deposits
Solves a specific problem: several separate payments you received (cash, cheques) show up on your bank statement as one lump-sum line. A Deposit batches those payments together so that one statement line can match all of them at once - it deliberately posts nothing new, since every payment inside it already posted for real when it was recorded. Once a deposit is matched to a statement line, everything in it locks.
Cash Management
A synthesis view, not a separate calculation engine - it reuses the same cash-position numbers as the Banking hub and the same forecasting logic Receivables and Payables already produce, so it can’t disagree with either. The distinctive piece is a forward cash projection in buckets (today, tomorrow, this week, this month, later) that nets expected money in against expected money out, including a scan of your bank history for recurring payments that aren’t already tied to a customer or vendor. It warns you in advance if the projected balance is ever expected to go negative.
Exceptions
A cross-account triage list of everything that needs a decision - unmatched transactions, statement lines with no reference to go on, possible duplicate payments, reconciliations with an unresolved variance, and stale accounts. It doesn’t resolve anything itself; every item links straight to the exact screen that does. Possible-duplicate detection (same customer or vendor, same amount, close together in time) is the one genuinely new piece of logic here.
Import
A single convenience step: pick which bank account you’re importing a statement for, and you’re taken straight into that account’s own Bank Transactions screen with the import dialog already open. It doesn’t do any importing itself.
Banking Intelligence
Trend analysis Cash Management doesn’t cover: month-over-month cash balance movement, reconciliation rate, average days to match a transaction, and separate trend lines for money actually collected from customers versus paid to vendors through the bank. An overall cash-health grade (healthy/attention/critical) summarizes all of it with the specific reasons behind the grade, over a selectable 3/6/12-month window.
Loans & Debt
A tracking registry for loans you owe - principal, outstanding balance, interest rate, next payment date. Recording a payment posts a real journal entry (debiting the loan’s own liability account and any interest expense you enter, crediting the bank account the payment left from) - it’s not a full amortization calculator, so you type in how much of each payment is interest rather than it being computed from a schedule. Above your configured approval threshold, a payment is held for a second person to approve before it posts, same as Fund Transfers. It also connects to Cash Management’s forecast: the next payment date feeds in as a labeled upcoming outflow if you’ve set it.
Payment File Export
Generates a downloadable NACHA, SEPA, or plain wire-instruction file from vendor payments you’ve already recorded and confirmed - built entirely on your device. AccountDesq never transmits money or talks to a bank directly; you still take the generated file to your bank yourself. Any beneficiary missing the bank details a format needs (routing + account, or IBAN + BIC) is flagged and skipped rather than silently left out.
Petty Cash
Models a classic cash-box (imprest system): a Voucher records a small expense but posts nothing by itself, so your book balance intentionally lags the real cash box between top-ups, exactly like a physical one would. Replenish is the one action that catches everything up - it recognizes the accumulated voucher expenses as a real entry and restores the float in one step, and a large enough replenishment amount goes through the same maker-checker approval as a Fund Transfer.
Positive Pay
A cheque fraud-control register: every cheque you issue is logged, then checked against what actually clears through the bank. Beyond the obvious "cleared for the wrong amount," it also catches a cheque clearing through a different bank account than the one it was issued from - exactly the kind of thing this control exists to catch. There’s no live bank feed behind it; it works entirely from what you’ve already recorded as vendor payments.
Watchlist Screening
A denied-party list you maintain yourself - an internal risk flag, a name legal told you to watch for, a past bad actor - checked by name similarity against every active customer and vendor. Deliberately not a live government sanctions/OFAC feed: that would be a real third-party dependency with its own staleness and licensing risk. Advisory only, same as Positive Pay - a hit never blocks a transaction or locks an account. If a hit turns out not to be a real match, you can record why and suppress it; the hit stays visible (dimmed, with your reason shown) rather than disappearing, and you can undo the suppression at any time.
Banking Reports & Audit
Five report views in one screen: Bank Register (the same underlying ledger register any Chart of Accounts account has), Cash Book (many accounts’ activity merged into one chronological view - genuinely new, nothing else in the app does this), Reconciliation Report, Bank Charges, and an Audit Log filtered to Banking activity. All five are date-ranged and exportable.
Matching Rules
Saved conditions (description contains, direction, amount range, optionally one specific account) paired with one action - auto-categorize to a GL account, or suggest a specific customer/vendor match. Rules never run silently in the background; they only fire when you click "Run rules" on a Bank Transactions screen, or use bulk-apply there. Testing a rule is built into the same drawer you create it in - there’s no separate "try it first" step.
Cash Sweep Rules
Automates a specific move: "if this account holds more than X, sweep everything above a reserve amount into that account." Running a sweep literally creates a Fund Transfer under the hood, so it automatically inherits the exact same approval threshold a manually created transfer would - nothing here bypasses that control. Sweeps only run when you click "Run," never on a schedule.
Fund Transfers
Moves money between your own bank accounts - not a customer or vendor payment. Below the configured threshold it posts immediately; at or above it, it’s held for a different person to approve before anything touches the ledger. The threshold that applies is whichever is tighter: the source account’s own override, if you’ve set one, wins over the workspace-wide default, because it’s the account losing the money that needs the stricter check.
Voiding a transfer reverses it - it never edits it
An approved or posted transfer can later be voided (a reason is required), which reverses the original journal entry rather than deleting or editing it - the same discipline as voiding a Payment. A transfer that was rejected, or is still waiting for approval, can’t be voided; it has to be rejected instead.
What happens to a bank statement line once it’s imported?
Every line ends up in exactly one of three states: Categorized (posts a new entry), Matched (linked to something already posted), or Ignored (no financial effect). There’s no fourth outcome, so a fully worked reconciliation always accounts for every imported line one of these three ways.
Can the person who creates a fund transfer also approve it?
No - Fund Transfers, Bank Adjustments, and Petty Cash Replenishment all share the same maker-checker rule: whoever created the transaction can never be the one who approves it, regardless of role or permission level.
Does AccountDesq move money directly between bank accounts?
No - AccountDesq never transmits money or connects directly to your bank. Payment Files and Positive Pay are file-generation and record-keeping tools that support your existing banking process; the actual money movement always happens through your bank.
Resources
Was this guide helpful?