Concord CRM Invoicing: From Won Deal to Paid Invoice

The pipeline says the team closed $148,000 last quarter. The bank statement says $96,000 landed. Nobody lied and no deal fell through - the two numbers are answering different questions. One counts signatures. The other counts money.

Most teams treat that gap as an admin chore: export the Won deals, retype them into an accounting tool, keep a spreadsheet of who still owes what. It is better read as a reporting defect. The real question is not how to invoice from Concord CRM, it is how to stop the CRM reporting revenue that has not arrived. Disclosure: we build and sell the Concord CRM invoicing module described here, so weigh the article accordingly.

Won means signed, not settled

Concord marks a deal Won at buyer commitment. That is the right definition for a sales pipeline: the stage records what the buyer agreed to, and once they have agreed the sales motion is over. The rep did their job and the deal should leave the board.

The trouble starts when people read the Won column as a revenue figure. Between signature and settlement sit invoice terms, the client’s own approval chain, a purchase order raised on their side, a payment run that happens on the 25th, and occasionally a dispute about one line item. On 30-day terms with ordinary slippage, a deal won in March is cash in May. The Won column has already banked it.

The fix is not to move the goalposts on Won. It is to add a second, financial closure point the sales stage does not control, so the CRM holds both facts about one deal at once: the sale is complete and the money is outstanding. They need separate visibility because they have different owners. A stalled sale needs a salesperson. A stalled payment needs finance, and eventually a decision about whether to keep working.

How to invoice from Concord CRM without leaving the deal

The loop is short: deal is won > invoice raised against that deal > client pays > deal advances to a financial stage. The invoicing module for Concord CRM adds a dedicated Invoice Management section inside the CRM where invoices are created, edited and tracked, so none of those steps happen in a second system.

The step people get wrong is the first: raise the invoice from the deal, not as a standalone document that happens to name the same client. That link is what makes the automatic stage progression work, powers the per-client revenue view, and lets you ask later why one deal took 74 days to turn into cash. An unlinked invoice gets you paid but teaches you nothing.

Custom fields belong on the invoice, not in the notes

Most billing relationships carry data that is neither the amount nor the client name: a purchase order number, a cost centre, a contract reference. The module supports custom fields on invoices, and they appear in the customer’s invoice preview and on the downloadable PDF. Put them there rather than in a description line - free text cannot be filtered on, and the commonest reason a correct invoice sits unpaid for six weeks is that it reached the client’s accounts payable inbox without the reference their system requires and was rejected silently.

Two email templates, two audiences

Notifications fire on two separate events with separately customisable templates, and they are not one message with two subject lines.

• Invoice creation is a request for action: amount, due date as an actual date rather than “net 30”, payment link. Everything else competes with the click.
• Payment confirmation is a receipt, and has to be findable in the client’s inbox nine months later: invoice number, amount, date, what it covered.

Templates can target admins as well as clients, which is how whoever chases debtors learns to stop.

Concord CRM Stripe and PayPal payments: who marks the invoice paid

The module accepts payment through Stripe and PayPal, covering credit cards, Apple Pay, Google Pay and digital wallets, and invoice status updates automatically as funds arrive.

That matters more than the list of accepted cards, because it changes who is responsible for the accuracy of your billing data. When a human marks invoices paid, the report is only as current as the last time that person sat down with a bank statement - usually Friday afternoon, and not at all during their holiday. When the gateway posts back, status is correct within minutes of settlement.

The boundary deserves stating. Anything collected outside those gateways - bank transfer, cheque, cash - still needs a person to record it, and automatic pipeline progression can only follow a payment the system knows about. That is not an argument against bank transfer, which on large B2B invoices is cheaper than card fees. It is an argument for reconciling the manual half in a fixed weekly slot rather than when someone remembers.

Put the payment link on every invoice regardless. A $340 balance is not worth a client’s approval process, and the person who takes three weeks to arrange a transfer will pay it from a phone in seconds.

The Invoice Paid stage is a reporting fix, not a nicety

When payment is received, the linked deal moves automatically to an Invoice Paid stage. That is the second closure point made concrete: sales completion and financial closure become separately observable events on one record.

Deal state	Invoice state	What it actually means	Who owns the next action
Won	No invoice raised	Revenue that exists only in the pipeline	Whoever closed the deal
Won	Unpaid	Signed and billed, nothing collected	Finance
Won	Partially paid	Deposit received, balance outstanding	Finance
Invoice Paid	Paid	Cash settled, the deal is finished	Nobody

The first row catches people out, and it is invisible without the separation. A deal in Won with no invoice against it is not yet a cash-flow problem - it is an admin gap, and the cheapest thing on the list to fix. Twenty minutes filtering for it usually turns up work that was delivered and never billed.

The Concord CRM Invoice Paid stage also gives you an interval measurable without a spreadsheet: days between a deal being won and its invoice settling. That is days sales outstanding on your own data. Use the median rather than the mean, because one 90-day enterprise client drags an average around and hides that everyone else pays inside a fortnight.

One consequence is worth deciding deliberately: if commission pays on Won, the sales team has no stake in whether the invoice ever settles. Moving the trigger to Invoice Paid puts the incentive where change is cheapest - in the negotiation, while the rep can still ask who raises the PO and when the client’s payment run happens.

Partially paid is the status that earns its keep

Every invoice carries a status of paid, partially paid or unpaid. The middle one does most of the work and is the one people skip past.

Project work rarely settles in a single movement. A 40% deposit up front and 60% on delivery is the standard shape, and a binary paid/unpaid world forces one of two bad habits: record the deposit as paid and lose sight of the balance, or leave the whole invoice unpaid so the receivables report overstates what you are owed by two and a half times.

That balance is also the line most likely to be forgotten, because the deal feels finished - deposit cleared, work shipped, rep already on next quarter. A status that keeps the outstanding 60% on screen inside the tool the team opens every morning beats a diligent process living in a spreadsheet nobody opens after the first month.

Permissions, and the client portal that is not there

Invoicing access is controlled per staff member through a role-based permission system, and it should be used narrowly. The instinct is to give the whole sales team create-and-edit rights because they know what was agreed. Resist it: editing a sent invoice is a financial control question rather than a convenience one, and far fewer people need to raise invoices than need to see them.

One limitation decides whether this is the right tool for you. Concord is built around internal team management rather than client-facing portals, and billing here is admin-controlled: your team creates, edits and manages invoices, and the client receives an emailed invoice with a payment link. There is no client login for browsing billing history at 11pm.

For most agency and consultancy relationships that is not a loss. But if you sell to procurement teams who expect self-service account access, that expectation will not be met here, and it is cheaper to know before you install than after.

Set it up in an afternoon

Installation and activation take a few minutes. Getting it to report truthfully takes the rest of the afternoon, in this order:

1. Connect one gateway first. Stripe or PayPal, whichever your clients already use. Two half-configured gateways are worse than one working one.
2. Add the Invoice Paid stage to the pipeline your closed deals land in, and confirm it sits after Won rather than replacing it. You want both events, not a renamed one.
3. Set permissions before anyone raises an invoice. Decide who creates, who edits and who only views; retrofitting once 200 invoices exist is far more awkward.
4. Create the custom fields your clients’ accounts payable systems demand and check they render on the PDF, not just on screen.
5. Rewrite both email templates. The invoice email is one of the few messages a client reads word for word.
6. Raise one real invoice end to end and pay it yourself with a small amount through the live gateway. Confirm the status flips and the deal advances on its own, then refund it.
7. Filter for Won deals with no invoice against them. Once now, and once a month afterwards.

Then leave it 30 days and pull one number: the median days between Won and Invoice Paid. If that is materially longer than your stated terms, the problem is not your invoicing software - it is your terms, your escalation, or a client relationship that needs an uncomfortable conversation. At least now you can point at which one.