Make a reminder recognisable and easy to check
Customers should not have to guess which invoice a message concerns. State the business sending it, invoice reference, due date, currency and current remaining amount. Describe the next step in ordinary language. A message can ask the customer to check an invoice or reply about a problem without presenting the balance as something they have already agreed is correct.
Use the right authorised contact rather than every address associated with a company. An operational contact may not handle payments; a shared accounts mailbox may be more appropriate. Check that a supplied invoice copy belongs to that customer and that personal or unrelated financial information is excluded. If the contact is wrong, hold follow-up while the business corrects it.
Give missing information a practical answer
A missing invoice copy, purchase-order number or explanation of a charge can block payment even when the customer intends to pay. The proposed workflow would route that question to someone who can supply the approved document or resolve the reference. Ordinary reminders should pause during that work. Sending the same demand again does not repair missing information.
Keep a working reply route in every proposed message and assign an owner to monitor it. State the invoice reference customers should include. If a customer asks for a copy, the owner should verify the recipient and source version before responding. This is document assistance around an issued invoice, not a promise that Procora creates or edits invoices.
Use an existing payment route only when it is approved
A business may already have a hosted invoice or payment page provided by its accounting or payment supplier. Including that existing link could be assessed within a future pilot, but no connection to such a page is confirmed for Procora’s invoice service. Check the destination, invoice association and access requirements before it appears in a message. A copied address alone is not a tested integration.
The customer would pay through their existing provider or agreed payment method. Procora would not initiate a bank transfer, store card details, approve credit, issue refunds or change bank details. It does not offer a native customer payment portal here. The public illustration has no real payment button and cannot request financial credentials or take money.
“Paid” is a reason to check, not a reason to close
In the fictional example, EX-101 has a £900 remaining balance as of 3 October 2026. The customer says it has been paid. The proposed next step is to acknowledge the reply, pause routine reminders and ask the responsible person to verify allocation in the accounting source. The status becomes Awaiting verification. The outstanding total remains £2,350 at that point.
A payment may be in transit, booked against another reference or waiting for allocation. Ask only for the reference and context needed to investigate through the agreed secure channel. Do not request bank login details. In the demonstration, a simulated verified £900 payment reduces EX-101 to £0, total outstanding to £1,450 and overdue to £650. No real payment occurs.
Handle part payments and requests for different terms
A part payment reduces the balance only once it is allocated. Future wording should show the remainder, rather than repeat the original gross amount. A promise to pay next Friday is a customer-stated date, not money received. Record the promise and give it an owner. Whether to pause reminders until that date is a decision governed by the business’s approved rules.
An instalment request goes to an authorised person. It does not automatically become an accepted arrangement or change the contract. An approved arrangement should record who agreed it and which dates and amounts apply. A duplicate-payment concern needs investigation before further requests. Procora’s proposed follow-up assistance does not decide refunds or negotiate payment terms autonomously.
Keep the relationship and the decision with the business
A disputed charge is a separate issue from a late reply. The proposed process would stop the usual reminder sequence, preserve the customer’s explanation and assign resolution to the owner. It should not escalate the tone simply because the invoice is older. Any decision about work quality, contract terms or a credit remains with the business and its authorised advisers.
Discuss where customers currently receive invoices, how they pay and where their replies arrive. Identify the questions that regularly interrupt payment and the person authorised to resolve each one. That gives a possible pilot a useful scope. This page describes a proposed service; submitting an enquiry does not activate reminders, create a payment account or change your customer’s terms.
Explore the example
Illustrative workflow · sample data · no messages or payments are processed.
EX-101 has £900 remaining. Check the current balance and contact before preparing a reminder.
- Outstanding
- £2,350
- Overdue
- £1,550
- Not yet due
- £800
Disputed subset: £650 · already included above; never added again.
As of 3 Oct 2026 · GBP · due-date ageing, remaining balances only.
| Invoice / customer | Due date | Remaining | State / age | Next action / owner | Last update |
|---|---|---|---|---|---|
| EX-101Example A | 18 Sept 2026 | £900 | Part-paid15 days overdue | Review balanceOwner A | 3 Oct 202609:00 UTC · sample snapshot |
| EX-102Example B | 3 Sept 2026 | £650 | Disputed · reminders paused30 days overdue | Resolve queryOwner B | 3 Oct 202609:00 UTC · sample snapshot |
| EX-103Example C | 25 Sept 2026 | £0 | Settled— | Close recordOwner A | 3 Oct 202609:00 UTC · sample snapshot |
| EX-104Example D | 10 Oct 2026 | £800 | Not yet due— | Check contactOwner B | 3 Oct 202609:00 UTC · sample snapshot |