Collect payment requests from anyone, route them through the right approvals, pay them, and land every one in your books as a proper double-entry transaction — without a second app or a second login.
Denise is the treasurer of a youth sports club. Money goes out constantly — a parent buys $42 of snacks for a tournament, a coach pays a $180 field permit, someone covers $60 of printing for the season schedule. It arrives as text messages with blurry receipt photos, forwarded emails, and one memorable note written on the back of an envelope. Denise reimburses people from a notebook, then tries to reconstruct the year at tax time. Last season she found four reimbursements she had paid twice, and one she never paid at all.
Almost nobody has a system for money leaving the business. Invoices coming in get an entire workflow; a $42 reimbursement gets a text message.
Informal payment requests break in three predictable ways: the request gets lost (buried in a thread), the approval is invisible (nobody can prove who said yes), and the books never hear about it (money moved, no entry).
Give people one place to submit, give approvers one queue to work, and make recording the payment part of paying it. That is the whole idea of PayFlow — and because it lives inside BizBooks Pro, the journal entry is one click from the approval, not a separate chore next Tuesday.
versus
1. What are the three ways informal payment requests fail?
PayFlow's portal is a web page your people log into — no app to install, nothing to buy on their side. You send an invitation link by email; they set a password and they are in.
Amount, category, what it was for, how urgent it is, and any deadline. They attach the receipt, invoice, or photo. Then they submit, and they can watch the status change without asking anyone.
Each portal user sees their own requests and nobody else's. A volunteer cannot browse what the treasurer approved for someone else; a subcontractor cannot see another sub's rates. You can activate, deactivate or remove access at any time.
Why this matters more than it sounds: the reason people text receipts is that the alternative is usually worse — a login they do not have, a form they cannot find, an accounting system they were never given access to. Remove that friction and the receipts arrive on their own.
2. What does someone need in order to submit a request?
Every submitted request lands in one dashboard inside BizBooks Pro. Not an inbox, not a folder — a queue you can sort, filter and act on.
Each row carries one-click actions, so the common case — approve this, it is obviously fine — takes a single click rather than opening a detail screen.
A bar chart on the dashboard breaks requests down by category, in both volume and dollars. This is usually the first time an organisation sees where its outgoing money actually goes — and it is common for the answer to be surprising.
Try this: filter to a single category for the last quarter. Most people discover one line item they had no idea was that large.
3. What do the colour-coded rows in the queue indicate?
Denise's sports club needs exactly one approval: hers. A general contractor with three active sites needs the project manager to confirm the work happened, then the owner to authorise anything over $1,000, then the bookkeeper to process it. Same software, same queue — different chain.
An approval chain is the sequence of people who must say yes before a request can be paid. You build it once and assign it; requests then route themselves.
Steps run in order. The second approver does not see the request until the first has approved it — which is the point: the owner should not be reviewing something the project manager has not yet confirmed.
The chain is not only about control — it is about evidence. Six months later, "who approved this?" has an answer that does not depend on anyone's memory, and the answer is attached to the request itself.
4. In a multi-step approval chain, when does the second approver see a request?
Approvers frequently need one more thing before they can say yes. PayFlow keeps that exchange on the request itself.
Because in six months the email is gone and the request is still there. An approval whose reasoning lives in someone's inbox is an approval nobody can audit.
A portal profile can be set to require a receipt — and the form will not submit without one. That check runs on the server, so a stale browser tab cannot slip past it.
Prefer some give? Requested mode asks for a receipt but lets someone explain instead — mileage, a cash tip, a vending machine — and files that explanation with the request, where an auditor can read it.
On storage: attachments sync down to your machine and the cloud copy is purged automatically after 30 days. The portal is a relay, not a filing cabinet — your documents end up local, with your books.
5. What happens if a portal profile requires a receipt and someone tries to submit without one?
This is the lesson that separates PayFlow from an approval app. Approving a request is workflow; recording it is accounting, and this is where the two meet.
You settle the money through your own bank — a Zelle send, a written cheque, an ACH transfer — then click Record Payment. Pick the debit and credit accounts, confirm the amount and date, and BizBooks Pro writes a proper double-entry journal, updates balances, and links the transaction back to the original request.
This closes the request without touching the books. It exists for the rare case where the payment was already entered another way. It sits behind a confirmation dialog on purpose, because closing a request without recording it is how money goes missing from a set of accounts.
A fix worth knowing about: these buttons used to be labelled "Mark Paid" and "Convert to Transaction", and people picked the wrong one constantly — the labels gave no clue which one wrote to the books. They were renamed, and every button now carries a plain-English tooltip explaining exactly what it does to your accounts.
A youth-organisation treasurer approves a $42.18 snack reimbursement. The parent's Zelle address is already on the request, so she sends it from the club's banking app, clicks Record Payment, and chooses Programs expense as the debit and Checking as the credit. Programs is debited $42.18, Checking is credited $42.18, and the request is closed and linked to the entry. Total elapsed time: under a minute.
If you use Mark Paid (No Entry) because it sounds simpler, your bank balance will drop and your books will not. Reconciliation will find it eventually — but you will be hunting for it months later with no idea what it was.
6. Which button writes the double-entry journal for a payment you settled through your bank?
The slowest part of paying someone is usually finding out how. PayFlow captures that at submission time, so the approver never has to chase it.
Paid someone once and now they are a regular? A single + Save as vendor click on the request turns that one-off recipient into a real vendor record in your books.
Every request carries a preferred payment method — Any, Zelle, Check, ACH, Cash or Other. The subcontractor who wants a cheque gets a cheque; the parent who wants Zelle gets Zelle. The system does not move the money itself; it makes sure you know how to.
Why the payee email matters: the person waiting for money is usually the person doing the chasing. Telling them directly that it has gone out removes most of the follow-up traffic before it starts.
7. Someone you paid once is becoming a regular supplier. What is the quickest route?
One generic form that half your people fill in wrongly is a common failure. Portal profiles let you build a different request form for each group you collect from, each with its own rules.
Turn any profile into a scannable QR code and download it as an image or a print-ready PDF. Post it on a job-site noticeboard or hand it round at a meeting, and people submit from their phones — no account, no password, no onboarding at all.
These forms accept submissions only. Nobody arriving via a QR code can see anyone else's request, or anything else in your books. It is a one-way letterbox, which is exactly what you want stuck to a wall.
Where this wins: a construction site with fifteen rotating subcontractors, a church hall of volunteers, a warehouse of seasonal staff — anywhere the population changes faster than you could ever issue logins.
8. Someone submits through a shared QR-code link. What can they see?
PayFlow's shape changes completely depending on who is using it. Here are five real patterns — find the one closest to you and copy its setup.
The problem: parents buy supplies, leaders pay permit fees, volunteers cover printing. It all arrives as texts and lost email attachments.
The setup: one-step chain (the treasurer). A volunteer profile with receipts requested — because someone genuinely did pay cash for parking. A QR code on the noticeboard so nobody needs an account.
The outcome: requests arrive organised by date, get approved, and become expense transactions. Parents check their own status instead of asking.
The problem: project managers at three sites submit subcontractor invoices and material requests daily. The owner wants eyes on anything over $1,000 before it is paid.
The setup: a three-step chain — PM, then owner, then accounting. Receipts required. A separate subcontractor profile demanding a job reference.
The outcome: the bookkeeper only ever sees fully authorised requests. Every dollar has a paper trail, and unapproved spending stops slipping through.
The problem: a rotating roster of freelancers, invoices arriving monthly in every conceivable format, needing sign-off from a project lead and a finance director.
The setup: freelancers submit through their own profile with the invoice attached. Two-step chain: project lead confirms the deliverable, finance director authorises payment.
The outcome: everything reaches accounting organised, documented and approved — instead of being forwarded around until someone acts.
The problem: hundreds of requests a month across North America, Europe and Asia-Pacific, in several currencies, with head office needing oversight without micromanaging from 8,000 miles away.
The setup: regional profiles, and chains that route small local spending to a regional manager while escalating larger amounts to the CFO. Quick links pinned to the dashboard for international banking portals.
The outcome: approved batches processed on a schedule, complete audit trail on every request, and full visibility without slowing anybody down.
The problem: plumbers, electricians and handymen invoicing after repairs; tenants occasionally seeking reimbursement for emergency work they paid for.
The setup: vendors upload invoices with job photos. Categories per building. A tenant profile separate from the trades profile.
The outcome: approvals from one queue, transactions recorded, and category reports pulled per building for each owner.
Every one of these is the same three moves: a form shaped for who is submitting, a chain shaped for who must agree, and a recorded journal entry at the end. What differs is only the shape.
9. What do all five organisations have in common?
Most organisations process payments on a rhythm — Friday afternoons, the 1st and the 15th, month end. PayFlow is built for that.
Pin shortcuts to the PayFlow dashboard — your bank's payment portal, your payroll provider, a vendor's site. When you are working thirty requests, not hunting for a bookmark each time adds up.
That last step is the one people forget exists. Because Record Payment writes a real journal entry against your bank account, those payments turn up in reconciliation exactly like every other transaction — no separate spreadsheet, no month-end surprise.
10. When you approve 30 requests as a batch, what happens in the audit trail?
This course teaches the workflow. The feature page lists every capability — approval chain builder, spend charts, portal controls, notification rules and the rest.
See all PayFlow features →Double-entry foundations, running a service business, and turning tracked hours into invoices — all free, all self-paced.
Browse all courses →