Subscription process: payments

Launching payment requests, monitoring receipt, and verifying the proof provided — with a reason list that doubles as a reconciliation checklist.

Overview

Kapitable does not move money. It issues the payment request with the beneficiary's details, records the proof the participant uploads, and tracks the state. The transfer happens at the participant's bank.

So "payment complete" on this screen means we have received and verified evidence of a transfer — not the platform debited someone. Keep that distinction when reading the statuses.

What you'll learn

What the payments table tells you
How to request bank details and payment
How to review and verify proof of payment
The named reasons a payment can be incomplete, and why they matter

Before you start

Transactions must be marked Ready (A8.5). If the table shows "No transactions are ready to be processed yet", that is why — payments follow readiness.

Steps

From the project Dashboard, open the process under Active Operations. On the Subscription Dashboard, go to Payments.
Where you need a participant's bank details, use Request Bank Info.
When you are ready for a participant to pay, use Request Payment. Nothing reaches them before this.
Monitor the table as requests progress. Use search and filters on a large process rather than scrolling.
Where a participant has not acted, Remind. Use Bulk to chase several at once.
When a participant submits proof, open the payment record and review it — the proof against the expected amount and payer.
When satisfied, verify the payment. That is the deal team's act, not an automatic one.
Where something is wrong, mark the payment incomplete with a reason, which returns the task to the participant.

Reading the table

Per transaction: Movement Type, Company, Issuer / Seller, Beneficiary / Buyer, Amount (€) and Status. You can search by name, company name or company registration number, and filter by type, status and Deferred payment only.

The status sequence runs roughly: Waiting setup → Seller invited / Beneficiary invited → Waiting bank info → Received bank info → Bank info complete → Waiting payment proof → Proof of payment received → Payment complete → Done.

Deferred is not a status but a flag, and it changes what the process can do. Until a payment is verified, that transaction's documents cannot be signed. Marking the payment deferred releases the signature so it can go ahead with funds still outstanding — which is why the table carries a Deferred payment only filter: it is the list of obligations owed against paper that is already signed. The decision is A8.11; setting it is A8.12.

Two statuses are worth recognising on sight:

Incomplete bank info — bank details were provided but are not usable.
Payment incomplete — a payment was provided but something does not reconcile.

Why a payment is incomplete

The platform names the reason rather than leaving you to guess, and the list is unusually thorough:

No proof of payment provided
The proof is incomplete or cannot be verified
The payment has not been received
The payment reference is missing, so the transfer cannot be matched
The reference does not match the expected subscription or investor
The payer's identity does not match the subscriber
A duplicate payment
Overpaid
Underpaid

That list is effectively a reconciliation checklist. Naming the right reason is what makes the participant's correction actionable, and what makes the process auditable afterwards.

What good looks like

Every transaction reaches Payment complete or Done, each having been reviewed and verified by a named person. The deal team and the finance side are reading the same screen — no separate funding tracker, no reconciling email threads.

Common problems

A payment cannot be matched to a subscription. The reference is missing or wrong. The most common reconciliation failure, and the reason the reference matters.

The amount does not match. Overpaid or underpaid — both are named reasons. Return the task rather than adjusting the expected amount to fit what arrived.

The payer is not the subscriber. Identity mismatch exists as a reason for good cause: a third party paying on someone's behalf is a compliance question, not a clerical one. Do not verify it to keep the process moving.

Nothing is happening. Check you have actually sent the request. Requests are never automatic.

A8.11 — Subscription process: choosing your payment and signature order · where payment sits in the sequence
A8.5 — Subscription process: reviewing before you commit · the readiness payments wait on
A8.14 — Subscription process: finishing and verifying · what completion enables
A8.10 — Subscription process: tracking signatures and sending reminders · the same chase pattern, for signature