Skip to content

Requests for payment (RFPs)

A request for payment (RFP) is the invoice-like document a buying group sends a supplier to collect a rebate — "you owe us £X for these rebate periods." The label is configurable per site (the RFP name setting), so it may appear as "Payment Request", "Invoice", or similar. RFPs are the outbound billing side of rebates; they are created and sent from the rebate management dashboard and tracked on their own RFP dashboard.

What an RFP is

An RFP has a header (supplier, deal, dates, total, VAT, terms) and one or more line items, each covering a rebate element and period. It is stored as an RFP record with RFPLine rows, and each line stamps the rebate payment it covers (so a rebate knows which RFP is collecting it). There is no separate reference number — the RFP's ID is its reference; an externalID links it to QuickBooks when accounting integration is on.

  • Single vs multi-line — a single RFP covers one deal/period; a multi-line RFP (when the site defaults to multi-line, optionally grouped by period end) bundles several periods/elements onto one document per deal.
  • VAT — applied per line from the site's RFP VAT rate.

Lifecycle

RFPs have no explicit status column; state is read from three fields:

State Meaning
Created The RFP exists, unpaid, due 30 days out (from creation)
Sent A sent date is stamped when it is emailed to the supplier
Paid Marked paid (or holding/incorrect) with a paid date, per line and header

Sending

Sending emails the deal's finance contact the RFP as a generated PDF attachment, through the campaign engine so opens and clicks are tracked. Bulk send groups outstanding rebates per finance contact and sends one email each. The PDF uses the site's RFP name and info text, and — on group sites — appends a per-member turnover/rebate breakdown page.

There is no supplier-facing acceptance or payment web page — the supplier receives the email and PDF; payment is recorded back on the platform by the group.

The RFP dashboard

The RFP dashboard (/rfp/dashboard) lists RFPs with filters for date range, paid state, supplier, deal category, sent-after, invoice age, and whether the RFP has an unresolved query, plus an export. Results are permission-filtered: category access is checked against the viewer's roles, and (with category security) non-admin members are limited to their category roles.

How RFPs lock figures entry

Once turnover for a deal/period has been invoiced through an RFP, that period's figures are locked from further editing for everyone except superusers. The turnover submission screen checks for an invoice-derived RFP line tied to the turnover and disables editing when one exists — so a rebate that has already been billed can't have its underlying figures changed out from under it.

Who can create and send RFPs

RFP actions require a logged-in user with the base view permission; the RFP endpoints carry no per-action role check, so who can create, send, or delete RFPs is enforced by the front end (the create/send actions live on the rebate dashboard, an admin/finance surface).

Why does an RFP change unexpectedly

  • A figures period locked — an RFP was created for it; invoiced periods lock figures entry.
  • An RFP shows a query/unresolved flag — a comment/query was raised against it.
  • Totals differ from expected — VAT handling differs between the rebate-request path (configurable rate) and the manual/remittance paths (hardcoded 20%).

What an RFP is not

  • Not a remittance advice — remittances are a separate RFP type, already-paid records of what was paid; RFPs request payment.
  • Not the rebate management dashboard — that tracks rebate payment state; the RFP is the billing document it generates.
  • Not a supplier self-service portal — delivery is email + PDF only.