Pay the bill and reconcile

Friday afternoon, fourteen bills, one click

It's 3pm on a Friday at a consultancy with about forty suppliers on regular terms. The bookkeeper opens the payables queue, ticks the fourteen bills due in the next week, sets the payment date to the following Wednesday, and submits the run. The approval policy catches it because the total is over £15,000; the finance director signs it off ten minutes later. By 3:20pm the BACS18 file is downloaded, uploaded to the bank's BACS portal, and the remittance emails have gone out. By Wednesday morning all fourteen suppliers have been paid in one batch, and on Wednesday afternoon the bank feed lands fourteen debits which the matcher reconciles automatically against the run.

Same consultancy, the following Monday morning. A contractor invoice lands at 9am — work completed Friday, payment requested this week, can't wait three days for the next BACS cycle. The bookkeeper opens the bill, clicks Pay now (Faster Payments), gets the instruction PDF, pastes the sort code and account number into the bank's manual payments screen, sends, and clicks Mark Paid. Total elapsed: about two minutes.

That's the shape of paying bills in Blankitt Finance Business. BACS for everything that can wait three days; FPS for everything that can't. Choose the route per bill, not per supplier; the same supplier might be on BACS most of the time and FPS for the occasional emergency.

The two ways to pay

BACS. Bulk. You compose a payment run containing multiple bills, generate a BACS Standard 18 file, upload it to your bank, and the bank settles all the payments on the agreed payment date. Clearing takes three working days from the payment date — submit Monday for a Wednesday payment date and the suppliers see funds on Friday. Cheap (your bank charges by the file, not by the line) and audit-clean (one file, one bank reference, one matcher pass).

Faster Payments (FPS). Single-pay. One bill at a time. You generate an instruction PDF with the supplier's sort code, account number, reference, and amount, then paste those details into your bank's online Send Money / Faster Payments screen and confirm the payment from the bank's portal. Clears in seconds. Same per-line cost as BACS at most banks; no bulk file format, so you stay in the bank's flow for the actual send.

The product doesn't initiate FPS transfers itself. There's no standardised FPS file format equivalent to BACS18 — every UK bank does single-payments differently — so we hand you the instruction and you complete the send from your bank. The audit trail picks back up when you click Mark Paid.

A few teams ask why we don't just send everything via FPS for the instant clearing. Two reasons: FPS has a per-payment fee at most banks (BACS bundles into a single file fee), and your finance director's policy almost certainly requires a documented approval gate, which is a lot more natural to enforce per-batch than per-payment. The hybrid model — BACS for routine, FPS for urgent — is what most finance teams settle on.

Composing a BACS payment run

1. Open Payments → New run and pick BACS as the method.
2. The picker lists every eligible bill: sent status, has a sort code + account number on the supplier contact, not yet in another open run. Tick the ones to include. The running total at the bottom updates live.
3. Set the payment date — the date you want the bank to debit your account, not today. This becomes the BACS file's processing-day field. Standard practice is payment-date = submission-date + 1 working day (so the file processes overnight and settles on day +3).
4. Click Submit. The approval policy fires (document type = payment_run). If a threshold matches, the run lands in pending_approval and the approver gets a notification. If no policy matches, the run auto-finalises.
5. From finalized, click Export and pick CSV or BACS18. The BACS18 file downloads, the run flips to exported, and remittance emails go out to suppliers with email on file (and who haven't opted out).
6. Log into your bank's BACS portal and upload the file.
7. When the bank confirms the credits have settled, return to the run and click Mark paid. Each item flips to paid, the bills update, and the final journal entries post.

The run holds at finalized until you click Export. That gap exists deliberately — once exported, the remittance emails have gone, and undoing the run becomes messy. Use the gap to double-check totals, supplier bank details, and the payment date.

Set your originator bank details on Company profile → Bank details before your first BACS run. The BACS18 format requires your own sort code and account number embedded in the file header; without them, the export errors. CSV exports still work without originator details (the bank-side template populates them), but BACS18 is what most banks want, so configure it once and forget.

Faster Payments single-pay

1. Open the bill (status must be sent or overdue — partial uses Record Payment instead, see below).
2. Click Pay now (Faster Payments) in the action bar.
3. Confirm the dialog. The system creates a one-item payment run with payment_method='fps' and runs the approval policy. If a threshold matches, the run lands in pending_approval for sign-off. If no policy matches, the run auto-finalises and the instruction PDF opens immediately.
4. The instruction PDF lists the destination details in monospace: sort code, account number, reference, amount, supplier name. Designed to be visually unambiguous — no proportional fonts that make a 1 and a 7 look alike.
5. Open your bank's Send Money / Faster Payments screen in a separate tab. Paste each field. Verify every digit against the PDF.
6. Send from the bank's portal.
7. Return to the payment run and click Mark paid. The bill flips to paid, the journal posts, and the remittance email (if the supplier has email on file) goes.

The supplier must have a sort code + account number on their contact record before the FPS button works. Without those the button errors with a clear message; add the details on the contact and retry.

The reference defaults to the bill number, truncated to 18 characters (the cross-bank-safe limit). Override it in the PDF request body if your supplier needs a different reference — typically a PO number or contract code.

FPS runs don't need your company's BACS originator details. You're sending from your bank's portal, not generating a bulk file, so the originator block isn't relevant. Even if Company profile → Bank details is empty, FPS works.

Partial payments — when you can't pay in full

Real-world bills don't always pay in one go. Record Payment on the bill detail page accepts an amount less than the bill total: the bill flips to partial, paid_amount tracks the running cumulative paid, and the outstanding figure (total − paid_amount) is what reconciliation and aged-creditor reports surface.

1. Open the bill (must be sent, overdue, or already partial).
2. Click Record Payment in the action bar.
3. Enter the amount you actually paid — anything less than outstanding is fine; equal to outstanding flips the bill straight to paid.
4. Pick the payment date and the bank account it came from. The journal posts on that date.
5. Confirm. The bill flips to partial (if it wasn't already), the journal posts (DR Accounts Payable, CR Cash), and the aged-creditor figure drops by your payment.
6. Next instalment? Open the same bill and click Record Next Payment. Same dialog, same flow.
7. Repeat until cumulative paid_amount equals total. The bill auto-flips to paid. No extra step.

Under cash-basis VAT, the VAT is apportioned proportionally. Pay 60% of a £1,200 + VAT bill and 60% of the VAT lands in Box 4 on the next VAT return. The matcher handles the apportionment automatically — you don't compute it by hand.

Under accrual-basis VAT, the full VAT was recognised when the bill was sent, so partial payments only move cash and the AP ledger; the VAT return isn't touched.

Overpaying is blocked. If you try to record a payment larger than the outstanding amount, the dialog errors. If you genuinely need to send the supplier more than the bill (an admin fee, a top-up, a deposit on a future order), record the bill total on this one and raise a separate bill or expense for the rest.

Remittance advice

On payment completion — when the run is exported (BACS) or marked paid (FPS) — the system emails the supplier a remittance advice. The email body lists which bills are being paid, the total, the payment reference, and the expected clearing date. A PDF version is attached for filing.

Remittance recipients are pulled from the supplier contact's email field. Suppliers with no email on file don't receive remittance — they get a flag on the run's audit log saying "no email; remittance skipped" — and you can manually email the PDF if needed.

Per-supplier opt-out lives on the contact record. Some suppliers explicitly ask not to receive remittances (they have their own portal and don't want duplicate notifications); some only want remittance for payments above a threshold; some want it on every penny. Configure per supplier under Contacts → [Supplier] → Remittance preferences.

Bank reconciliation

The bank feed pulls daily from your connected accounts (via Open Banking for most UK banks). Inbound transactions land in Bank → Unreconciled with a timestamp, amount, and reference.

The matcher runs over every new transaction and tries to match it to an outstanding payment record by:

• Amount. Within a configurable tolerance (default 1p for FX rounding, 0p for GBP).
• Date. Within a configurable window of the expected payment date (default ±3 working days for BACS, ±1 for FPS).
• Reference. Substring match on the bank's reference field against the payment reference and supplier name.

When all three align, the transaction auto-matches to the payment, the payment flips to reconciled, and the bill's audit chain closes. The matcher is outstanding-aware: it won't suggest a match that would over-pay a bill, and it handles split transactions (a single bank debit covering multiple bills) by looking for payment-run-level matches before bill-level ones.

When the matcher can't find a match, the transaction stays in Bank → Unreconciled. You review it, either click Match manually and pick the payment from a list, or click Create transaction to log it as a non-bill expense (bank fees, interest, transfers).

Reconcile at least monthly. Quarterly reconciliation lets duplicate payments live undetected for up to three months — long enough for the supplier to forget the conversation and the audit trail to go cold.

"Paid" vs "reconciled"

These are different states. They look the same when everything's going well, but the difference matters when something goes wrong.

Paid means: you've sent the money. You clicked Mark Paid, the bill flipped to paid, the journal posted, the remittance went out. From your accounting system's point of view, the transaction is complete.

Reconciled means: the bank statement confirms the money actually left your account. The bank feed delivered a transaction matching the payment; the matcher linked them.

For FPS, paid and reconciled usually happen on the same day — sometimes within minutes. For BACS, there's a three-working-day gap by design.

For both, the gap between paid and reconciled is where errors hide. A BACS file that the bank rejected; an FPS payment that bounced because the account details were wrong; a duplicate transaction created because someone clicked Mark Paid twice. Reconciliation is the loop-closer: if the bank doesn't confirm, the payment didn't actually happen, and you need to investigate.

The full audit trail

By the time a bill is reconciled, the system holds a complete evidence chain:

• PR.justification — who asked, why, and what they planned to spend it on.
• PR.approved_by + approval_log — who said yes, when, and what policy matched.
• PO.pdf + PO.sent_at + fin_po_email_log — the document the supplier received, the date it went, and the message-id of the email send.
• GRN.received_at + grn_lines — what arrived, how much, when, and who recorded it.
• Bill.uploaded_file + bill.ocr_fields — the supplier's invoice as a PDF, plus the structured data extracted from it.
• Bill.match_status — three-way match outcome.
• PaymentRun.bacs_file_id (or FPS instruction PDF) — the file the bank received, or the instruction you pasted into the bank's portal.
• PaymentRun.marked_paid_at + paid_by_user_id — operator confirmation that the bank had confirmed the send.
• Bank match record — the actual statement line that confirmed the money moved, linked back to the payment.

Any one of those records can be pulled up in an audit, a supplier dispute, or an internal review. The chain links them. You're never asked "did we actually pay this bill?" and stuck with a blank — the answer is queryable in any direction: from the bank line up to the PR, or from the PR down to the bank line.

Common mistakes

Marking paid before the bank confirms. Eager bookkeepers click Mark Paid as soon as the BACS file uploads. If the bank rejects the file (often for an originator-detail mismatch), the bills are flagged paid in your system but no money has moved. Suppliers chase you for payments that never landed; the matcher can't reconcile because there's no bank line; you spend a morning untangling it. Mark Paid after the bank confirms, not before.

Forgetting per-supplier opt-out. A supplier explicitly asks not to receive remittance; nobody updates the contact record; the run-export fires off a remittance email anyway. Annoying for the supplier, easy to miss until they complain. Configure opt-out on the contact the moment a supplier asks.

Compositing PRs into payment runs. Payment runs only contain bills. PRs aren't payable (nothing's been committed yet); POs aren't payable (no invoice received). The picker filters by status, so this is mostly self-correcting — but new users sometimes wonder why a PR they've raised isn't showing in the run picker. Answer: because it's not a bill yet.

Running BACS files through a personal bank account. It happens — usually a sole director funding a quick payment from a personal card. The BACS file references the company originator details, the bank rejects it because the account doesn't match, and you spend ten minutes wondering why. Originator details in the company profile must match the bank account you're submitting the file from.

Not reconciling until quarter-end. The Pythagoras-of-AP error. By the time you reconcile at quarter-end you've forgotten which bill was which, the bank reference doesn't match the supplier name, and the matcher's date-tolerance windows are blown. Reconcile weekly if you can; monthly at the absolute outside.

Where the cycle closes

That's the full AP cycle: from "we need to spend money" through approval, commitment, receipt, billing, payment, and reconciliation. Six stages, each writing evidence the next consumes, all queryable end-to-end.

Closing the books — month-end, year-end, statutory accounts — is a separate concern. It uses the AP audit trail as input (commitments register, accruals from un-received POs, aged creditors) but operates on top of it rather than as part of it. That's covered in a separate series; if you've made it through the six chapters of the AP cycle, you've got the foundation everything downstream relies on.

The next time a bill arrives, you'll know what shape it ought to fit into — and what the gap means when it doesn't.