💳Payment Requests, End to End

Take requests from staff, volunteers, contractors and vendors; send each down the right approval path; pay it; and have the books updated correctly the moment you do — all inside the software you already keep the accounts in.

10
Lessons
~63
Minutes
100%
Free
Course Progress
0%
Score
0

📚 Course Outline

  1. The Request Nobody Can Find
  2. How a Request Gets In
  3. The Queue You Work From
  4. Deciding Who Signs Off
  5. Asking Questions and Holding the Paperwork
  6. Settling It, and Getting the Entry Right
  7. Who Gets Paid, and How They Want It
  8. Different Forms for Different Groups
  9. The Same Tool in Five Very Different Places
  10. Processing in Bulk and Closing the Loop
1

The Request Nobody Can Find

5 minutes · What informal approvals actually cost
Start
Meet Halvard

Halvard runs a nine-person landscaping outfit. His crew leads buy materials on the way to jobs — a $210 pallet of turf here, $75 of irrigation fittings there, fuel, tip fees, the odd tool that broke that morning. Every one of those arrives as a photo in a group chat. Halvard pays people back on Fridays from memory. Last quarter his accountant found $3,400 of purchases with no receipt attached to anything, and a crew lead had gone two months without being paid back for a $190 charge because the photo scrolled away.

Businesses build careful processes for money coming in and almost none for money going out. An invoice gets terms, a due date and a reminder schedule; a $210 reimbursement gets a group chat.

Three Ways It Breaks

Casual payment requests fail predictably. The request disappears into a thread. The approval leaves no evidence — nobody can show who authorised what. And the accounts never learn of it, so money has moved with no matching entry.

The Symptoms You Will Recognise

  • The chase — "any word on that receipt?" asked repeatedly, because there is no status to look at
  • Verbal sign-off — authorisation that exists only in somebody's recollection
  • Receipts nowhere useful — a camera roll is not a filing system
  • Paying twice — two people settle the same thing a week apart
  • Reverse-engineering the year — working out what a payment was for from a bank line

What Changes With a Queue

One route in for the person spending money, one list for whoever approves it, and recording the entry built into settling it. Because PayFlow sits inside Kantivo rather than beside it, the bookkeeping happens at the moment of approval instead of becoming next week's problem.

📱 Photo in a chat
🤔 Hope
😕 Guesswork

compared with

🌐 Submitted
⚖ Authorised
📝 On the books

Quick Check

1. Which three things go wrong when payment requests are handled casually?

The bank charges a fee for each one
The request vanishes, the authorisation leaves no trace, and the accounts are never updated
Staff submit far too many of them
They need their own bank account
2

How a Request Gets In

6 minutes · One route in, from any browser
Locked

The portal is simply a web page. Whoever needs to ask you for money opens it in a browser — there is nothing to install and no licence to buy for them. You email an invitation link, they choose a password, and that is the onboarding.

The Form Itself

How much, which category, what it was for, how urgent, and a deadline if there is one — plus the receipt, invoice or photograph attached. After submitting they can follow the status themselves instead of asking you.

Who Ends Up With a Login

  • Staff — expenses and requests to buy something
  • Volunteers — getting money back for what they bought on your behalf
  • Freelancers and subcontractors — submitting their own invoices rather than emailing them
  • Suppliers — bills arriving with their paperwork already attached
  • Managers away from the office — spending requests from a phone on site

Everyone in Their Own Lane

A portal user sees only what they submitted. One volunteer cannot read another's claim; one subcontractor cannot see a rival's rates. Access can be switched on, suspended or revoked whenever you like.

An underrated point: people text receipts because the official route is harder than texting. If asking properly takes thirty seconds in a browser, the paperwork starts arriving without anyone having to nag.

Quick Check

2. What does a submitter need before they can send you a request?

Their own paid licence for the software
A browser and the invitation link you sent
To install a mobile app first
Access to your chart of accounts
3

The Queue You Work From

6 minutes · Everything waiting, in one filterable list
Locked

Submitted requests all arrive in a single dashboard inside Kantivo. It behaves like a work queue rather than an inbox: sortable, filterable, and actionable in place.

Narrowing the List

  • Status — awaiting a decision, approved, declined, settled
  • Urgency — rows are colour-coded by priority so the pressing ones surface
  • Date or value — say, everything above $1,000 raised this month
  • Free text — search what was written in the description

Acting Without Opening Anything

Buttons sit on the row itself. The routine decision — this is fine, approve it — is one click, with no need to open the full record first.

Where the Money Actually Goes

The dashboard charts requests by category, both in count and in value. For a lot of organisations this is the first honest picture they have had of their outgoings, and the largest bar is rarely the one they expected.

Worth doing once: filter to one category across a full quarter. There is almost always a line that is bigger than anyone assumed.

Quick Check

3. What is the colour coding on a queue row telling you?

The account that will be debited
How urgent the request is
Whether a staff member submitted it
How old the receipt is
4

Deciding Who Signs Off

7 minutes · One approver, or several in order
Locked
The Same Tool, Two Shapes

Halvard's landscaping business needs one signature — his. A regional builder running three sites wants the site manager to confirm the materials arrived, the director to authorise anything past $1,000, and then the bookkeeper to settle it. Identical software, identical queue, entirely different routing.

A chain is simply the order in which people must agree before money can go out. Build it once, attach it, and requests find their own way through.

One After Another

Approvals are sequential. Nobody further down the chain sees a request until the person before them has agreed — deliberately, because a director should not be adjudicating something the site manager has not yet verified.

Shapes That Work

  • A single approver — treasurer, owner, sole practitioner. This is where most start.
  • Two in sequence — whoever can confirm the work was done, then whoever holds the purse.
  • Three in sequence — site, ownership, accounts. Typical wherever a spending threshold exists.
  • A chain per category — small reimbursements go the short way, equipment purchases go the long way.

Routing Is Half the Value; Evidence Is the Other Half

A chain governs who decides, but it also leaves proof. When somebody asks next year who authorised a payment, the answer is recorded against the request rather than reconstructed from recollection.

Quick Check

4. At what point does the second approver in a chain see the request?

At the same moment as the first
Only once the first has approved it
Only when the value exceeds $1,000
After the money has already gone
5

Asking Questions and Holding the Paperwork

6 minutes · Keep the conversation with the record
Locked

Most approvals stall on one missing detail. Rather than starting an email thread, you ask on the record itself.

Threaded Messages

  • Post the question straight onto the request
  • The submitter reads and answers it in the portal
  • Email alerts fire in both directions when something new arrives
  • The exchange stays fixed to the request, permanently and in context

The Case Against Email

A year on, the mail thread has been archived, filtered or lost with a laptop — while the request is exactly where you left it. Reasoning that lives in an inbox cannot be audited.

Making a Receipt Compulsory

A profile can be set so a receipt is mandatory, and the form simply will not go through without one. The rule is enforced server-side, so an old browser tab cannot dodge it.

Want some latitude? Requested mode asks for the receipt but accepts a written reason in its place — mileage, a cash tip, a vending machine — and stores that reason on the request for whoever reviews it later.

Where the files live: attachments come down to your own machine, and the cloud copy is cleared after 30 days. The portal moves documents; it does not hoard them — the originals sit locally alongside your accounts.

Quick Check

5. A profile makes receipts mandatory. What happens if someone submits without attaching one?

It goes through and is flagged for later review
It is refused; the rule is checked on the server
The approver is emailed instead
The request is discarded
6

Settling It, and Getting the Entry Right

7 minutes · Three buttons, one of which you almost always want
Locked

Here is where this stops being an approvals tool. Agreeing to a payment is workflow. Booking it is accounting — and this is the join.

Record Payment — nearly always the right button

Move the money however you normally do — Zelle from the banking app, a cheque, an ACH run — then press Record Payment. Choose which account to debit and which to credit, check the figure and the date, and Kantivo posts a full double-entry journal, recalculates balances, and ties the transaction back to the request it came from.

Mark Paid (No Entry) — rarely what you want

It closes the request and writes nothing to the accounts. It is there for the unusual case where the payment was already booked by another route, and it is deliberately guarded by a confirmation prompt — because closing a request without an entry is precisely how a payment vanishes from a set of books.

A usability fix worth knowing: these were once called "Mark Paid" and "Convert to Transaction", and people chose wrongly all the time — nothing in the wording said which one touched the accounts. Both were renamed, and each button now explains itself in a hover tooltip.

Start to Finish

A club treasurer approves a $42.18 claim for snacks. The parent's Zelle address is already sitting on the request, so she pays it from the club's banking app, hits Record Payment, and selects Programs as the debit and Checking as the credit. Programs goes up $42.18, Checking comes down $42.18, the request closes, and the entry is linked to it. Well under a minute, start to finish.

⚠️ The error to watch for

Reach for Mark Paid (No Entry) because it looks like the shorter path and your bank balance falls while your accounts stay put. A reconciliation will surface it eventually, months later, with nothing to explain what it was.

Quick Check

6. You paid via your bank. Which button posts the double-entry journal?

Mark Paid (No Entry)
Record Payment
Approve
Close Request
7

Who Gets Paid, and How They Want It

6 minutes · Payment details arrive with the request
Locked

What normally holds up a payment is not the decision — it is working out how to send it. Those details are collected when the request is raised, so nobody has to go looking later.

Two Flavours

  • Money back to me — takes the submitter's own payment details from their portal profile
  • Money to a supplier — pick from the vendors you already have, or record a one-time recipient there and then

Turning a One-Off Into a Vendor

If that one-time payee turns into a regular, + Save as vendor on the request promotes them into a proper vendor record in your books with a single click.

Paying People the Way They Asked

Each request carries a preferred method — Any, Zelle, Check, ACH, Cash or Other. A subcontractor who wants a cheque gets one; a parent who prefers Zelle gets Zelle. The software does not move the funds; it makes certain you know exactly how they should be moved.

The Right Email to the Right Person

  • Whoever submitted hears about each meaningful status change
  • Whoever is being paid receives their own "payment is on its way" note, not a forwarded internal one
  • "Also notify" adds extra addresses to any single request
  • Set the default once for the company, then override it where a request warrants it

Why the payee note earns its keep: the person owed money is the person who chases. Tell them it has been sent and most of that chasing never happens.

Quick Check

7. A one-off recipient is turning into a regular. What is the fastest way to formalise them?

Type them into the vendor list by hand
Use "+ Save as vendor" on the request itself
Have them sign up to the portal a second time
Nothing; one-off payees stay one-off
8

Different Forms for Different Groups

6 minutes · Tailored forms, and a code people can scan
Locked

A single catch-all form that half the people complete incorrectly is a familiar problem. Profiles solve it by giving each group its own version of the form, with its own requirements.

What That Looks Like

  • Crews on site — materials and fuel, receipt compulsory
  • Subcontractors — invoice number and job code required
  • Volunteers — modest claims, receipt asked for but not enforced
  • Department leads — purchase requests carrying a category and a needed-by date

A Link, or a Code on the Wall

Any profile converts into a QR code, downloadable as an image or a print-ready PDF. Pin it up on site or pass it round a meeting and people submit straight from their phones — with no account, no password and no setup whatsoever.

Why a Public Code Is Still Safe

A shared form takes submissions and gives nothing back. Someone scanning that code cannot view another person's request, let alone anything in your accounts. It is a letterbox — which is the only thing you would want pinned to a public wall.

Where it really pays: a site with subcontractors who change every fortnight, a hall full of volunteers, a seasonal warehouse crew — any group that turns over faster than you could issue logins.

Quick Check

8. A person submits via a shared QR code. What are they able to view?

Every request in the same category
Only what they sent; the form takes submissions and displays nothing
The whole processing queue
Your chart of accounts
9

The Same Tool in Five Very Different Places

8 minutes · Five setups worth stealing from
Locked

How PayFlow is configured depends entirely on the organisation around it. Five patterns follow — pick whichever sits nearest to your own and borrow its setup.

🏛 A Charity Treasurer

The difficulty: parents buying supplies, leaders paying permit fees, volunteers covering printing — all landing as messages and mislaid attachments.

The configuration: a single approver. A volunteer form where a receipt is asked for but not insisted upon, since someone really did pay cash for parking. A QR code on the noticeboard, so no logins are needed at all.

The result: claims arrive in date order, get approved, and turn into expense entries. Volunteers watch their own progress rather than asking.

🏗 A Building Firm

The difficulty: managers across three sites raising subcontractor invoices and materials orders daily, with the director wanting sight of anything past $1,000 before it is settled.

The configuration: three approvals in sequence — manager, director, then accounts. Receipts compulsory. Subcontractors get their own form demanding a job code.

The result: whoever does the books only ever sees fully authorised items, every payment carries its trail, and nothing unapproved slips out.

💼 A Consultancy

The difficulty: a changing bench of freelancers submitting invoices monthly in a dozen formats, each needing a project lead and a finance director to agree.

The configuration: freelancers submit on their own form with the invoice attached; two approvals — the lead confirms the work landed, the finance director releases the money.

The result: accounts receive work that is already tidy, evidenced and authorised, rather than an email forwarded until somebody finally acts.

🌎 A Multinational

The difficulty: hundreds of requests monthly across three continents and several currencies, with head office needing oversight but no appetite for micromanaging from another hemisphere.

The configuration: a form per region, and chains that keep modest local spending with the regional manager while pushing larger sums to the CFO. Banking portals pinned to the dashboard as quick links.

The result: authorised batches processed to a timetable, an audit trail on every item, and genuine visibility that costs nobody any speed.

🏠 A Letting Agent

The difficulty: trades invoicing after repairs, and tenants occasionally claiming back emergency work they funded themselves.

The configuration: trades upload invoices with photographs of the job; categories set per building; tenants given a form of their own, separate from the trades one.

The result: one queue to approve from, entries recorded as you go, and per-building category reports for each landlord.

What They All Share

Each of these is the same three decisions: a form built around who is submitting, a chain built around who must agree, and a journal entry at the close. Only the proportions change.

Quick Check

9. What is identical across all five of these setups?

All of them use three approval steps
A form suited to the submitter, a chain suited to the approvers, and an entry on the books at the end
Every one demands a receipt on every request
They all settle by Zelle
10

Processing in Bulk and Closing the Loop

6 minutes · Clearing a backlog properly
Locked

Payments tend to run on a cycle — Friday afternoon, the 1st and the 15th, the end of the month. The queue is designed around that habit.

Handling Them in Bulk

  • Filter down to the set you are dealing with — a category, a value band, everything outstanding
  • Select the lot and approve or decline in a single action
  • Each one is still recorded separately in the audit trail — processing together does not mean logging together

Shortcuts Where You Work

Pin links onto the dashboard — the bank's payment page, your payroll provider, a supplier's site. Across thirty requests, not going hunting for a bookmark every time is a real saving.

The Whole Circuit

Raised
Authorised
Paid
Booked
Reconciled

The final step is the one nobody anticipates. Since Record Payment posts a genuine journal entry against the bank account, these payments appear in your reconciliation like any other line — no side spreadsheet, no unpleasant discovery at month end.

A Sensible First Week

  1. Invite the three people who ask you for money most often
  2. Create one chain — a single approver is fine; extend it later
  3. Set categories that match how you already think about spending
  4. Run one genuine request the whole way through, Record Payment included
  5. Leave profiles, QR codes and batching until after that works

Quick Check

10. You approve thirty requests at once. How does the audit trail treat that?

A single entry covers the batch
Each action is recorded on its own
Bulk actions are not logged
Only the rejections are logged
🏆

That's the whole workflow

You can now take a payment request from a phone on a job site all the way to a reconciled journal entry — with the approval, the receipt and the audit trail attached to it the entire way.

Want to run it on your own books?

Try Kantivo Free for 30 Days

Want the full PayFlow reference?

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 →

More courses in this library

Double-entry foundations, running a service business, and turning tracked hours into invoices — all free, all self-paced.

Browse all courses →