Skip to main content

All postsRevOps

Recruit CRM Placement Fee Reconciliation: From Fee to Cash

Use a placement, invoice, and payment evidence trail to find missing fees, partial payments, and disputed balances without treating a CRM status as a bank receipt.

Ops Automators
8 min read
Part of the guide:Finance and Billing Automation: Handoffs You Can Reconcile
Cover image for Recruit CRM Placement Fee Reconciliation: From Fee to Cash

The placement is marked complete. The recruiter can see a fee. Finance cannot find the invoice, or the invoice shows paid while the bank feed has no matching receipt. Those are three different records with three different jobs.

Recruit CRM now lets teams create invoices from placement records, enter a placement fee and dates, track invoice statuses, and retain invoice-status history. That can make a useful native starting point. It does not turn a CRM status into independent evidence that cash settled in the agency's bank or payment system. Recruit CRM's current invoice guide is the source for those native capabilities, checked October 19, 2026.

This is a reconciliation method, not a claim about a connected Recruit CRM account. The records below are synthetic USD examples. Replace the fields, approval rules, payment source, and retention approach with the rules your firm has actually adopted.

Start with the question you need answered

Choose one decision before building a report:

  • Has every billable placement produced the right approved invoice?
  • Which issued invoices still lack payment evidence after their due date?
  • Which payments need a human to allocate, because they are partial, unmatched, or tied to a credit?

Do not call all three questions "revenue." A placement fee can support a booked-fee report. An issued invoice can support a billed-amount report. Cash collected needs payment-system or bank evidence with an allocation to the invoice. If leadership wants all three, keep the measures separate.

Check the native record path first

Before adding an integration or a warehouse, test a small, real internal sample with the people who own placement and billing records. Recruit CRM documents invoice creation from supported records including placements, templates that can include a placement fee, invoice exports, internal custom fields, invoice status history, and a lock after an invoice is marked Paid. It also documents the Paid, Due, and Overdue views in the invoice list. Confirm the account's plan, permissions, configuration, and actual invoice template before assuming any of those fields exist in your workflow.

For the test, record:

Check Evidence to retain Why it matters
Placement key and approved fee Placement ID, client, currency, agreed fee, approver, and approved date A fee field alone may be a draft or an outdated commercial term.
Invoice link Recruit CRM invoice ID/number, issue date, due date, currency, and placement reference This is the bridge between an agreed placement and a billed amount.
Payment evidence Accounting-system receipt ID, payment-provider transaction, or bank-feed reference A CRM Paid status does not independently prove a bank receipt.
Allocation Amount applied, payment date, remaining balance, and allocator A payment can cover only part of an invoice or more than one invoice.
Exception owner Person and queue for missing, duplicate, disputed, or currency-mismatched records A notification is not a resolution path.

If the native invoice record, exports, and a documented manual payment check answer the question at your volume, stop there. An external model is justified when the required payment evidence lives elsewhere, a recurring allocation cannot be reviewed safely in a spreadsheet, or reporting needs a stable history across systems.

A worked reconciliation table

The following table is a design exercise. It does not describe Recruit CRM's data model, an observed payment synchronization, or customer records.

PlacementApproved feeRecruit CRM invoicePayment evidenceReconciliation stateNext action
P-104USD 12,000INV-410, USD 12,000, Sent to ClientBank receipt BR-88, USD 12,000, reference INV-410MatchedRetain the links and close the review item.
P-105USD 9,500INV-411, USD 9,500, PaidNo accounting or bank reference suppliedNeeds evidenceAsk finance to confirm or correct the payment evidence. Do not report this as collected cash yet.
P-106USD 15,000INV-412, USD 15,000, Sent to ClientReceipt BR-89, USD 6,000, reference INV-412Partially paidAllocate USD 6,000 and leave USD 9,000 outstanding. Keep the invoice open under the firm's policy.
P-107USD 8,000No invoice IDNoneMissing invoiceConfirm the placement is billable, then route invoice creation or the exception to the billing owner.
P-108USD 10,000INV-413, USD 10,000, PaidReceipt BR-90, USD 10,000; credit note CN-12; no refund referenceReview credit treatmentLink the credit note, define gross and net billing, and record any refund separately only with its own payment or bank reference.

The first row gives a complete fee-to-cash chain. The second does not. The third is not a failure just because the invoice is not fully settled. The fourth is where a placement-to-invoice control earns its keep. The final row shows why a payment amount alone cannot answer every financial question.

Match records with stable keys, then review the leftovers

Start with stable IDs, not a client name typed by two people. Preserve the placement ID on the billing record where your configuration supports it. Preserve the Recruit CRM invoice number or ID on the payment-side record or allocation table. Retain the original currency with every amount.

An automated match should produce an exception, not a guessed write, when it sees any of these conditions:

  • a placement with an approved fee and no invoice reference after the agreed billing trigger;
  • more than one invoice linked to the same placement without a documented amendment or split-billing rule;
  • an invoice amount that differs from the approved fee without an approved adjustment record;
  • a payment that cannot be allocated by a stable invoice reference;
  • a payment that is smaller than the invoice balance;
  • a credit note, refund, write-off, or foreign-currency conversion that changes the amount a report is meant to show.

Those are design conditions. They need real policy decisions before an automation can change invoice or payment status. Keep any uncertain write in a review queue. For an example of a tested, synthetic invoice review gate that stops before creating an invoice or marking it paid, see the n8n invoice review implementation note.

Keep the reporting layers honest

A weekly finance view can show several valid totals, as long as the labels say what they represent:

Measure Source boundary Do not infer
Approved placement fees Approved placement terms That an invoice was issued or money arrived.
Invoiced amount Issued invoice records, adjusted for the reporting definition That every invoice is collectible or paid.
Cash allocated Payment-system or bank evidence allocated to invoice records That it equals booked or billed revenue.
Outstanding balance Invoice amount less recorded allocations, subject to credit and dispute rules That an overdue record is uncollectible.

This separation also prevents an easy reporting error: treating a current invoice status as a historical payment timeline. Recruit CRM documents invoice status history. Check whether that history, its exports, and the payment evidence your finance team uses supply the dates and fields your report requires. If not, record observed collection dates only from the system that owns them.

Decide whether the next step is configuration, a control, or an integration

Do not commission a full pipeline just because a monthly spreadsheet has awkward rows. A native invoice template and an internal tracking field, backed by a documented review check, may close the gap. A shared reconciliation worksheet may be enough if volume is low and finance can review every exception. An integration becomes useful when the agency has a settled matching rule, an authoritative payment source, named owners, and acceptance cases for partial payments, credits, and retries.

Our Recruit CRM reporting guide covers the separate decision between native reporting and a data model for historical or cross-system questions. Recruit CRM consulting can help document the record ownership, billing evidence, exception flow, and acceptance checks before any external write is enabled. Bring one redacted placement, its expected invoice, and the payment evidence finance would accept.

Have a similar operating problem?

Tell us about the process and the decision you need to make.