Workflow break check · your result
Where your deal-closed-to-billing hand-off typically breaks
These are the places setups like yours usually fail; they are not findings about your systems, since nothing here looked at them. Each one comes with a way to check it yourself. Navceed is being built to run checks of these six kinds; today it runs them on an example company, and you can connect your own tools; changing anything in them is coming next.
1. The first invoice is created but never sent
Check firstInvoiceRun by finance or sales opsabout 10 min
Shown because you answered “It depends on the kind of deal, and nobody tracks the unsent ones”; “Someone notices and tells us”.
How to check, and why it happens
The subscription or order exists, but its first invoice sits as a draft that nobody finalises or sends. The customer is not asked to pay, and the date money is expected drifts.
Why it happens. In some tools the first invoice is created as a draft on purpose, so it can be edited, and it needs a setting or a person to send it. Other tools default differently.
Usually fixed by: Finance operations.
Kind of break, one of six: Freshness: is the step still running, and on time? Arrival: did it show up in the next tool in time?
Sources: Vendor documentation · Vendor documentation
2. A won deal never becomes a customer in billing
Check firstHandoverRun by finance or sales opsabout 20 min
Shown because you answered “Someone notices and tells us”; “Automatically, and nobody checks”.
How to check, and why it happens
A deal is marked won, but no customer or subscription appears in your billing tool, or it appears days later. The deal looks finished on the sales side, so nobody asks.
Why it happens. The hand-off needs a trigger (a button, a stage change, a complete record). In some tools a deal missing a product line, a contact or a company is not sent, or waits until someone presses the button.
Usually fixed by: Sales operations (when a deal may be marked won, and what must be filled in), with finance operations.
Kind of break, one of six: Arrival: did it show up in the next tool in time?
Sources: Integration vendor guide · Integration vendor guide
3. The first invoice is held up because the customer's address is too thin
Check firstCustomerRun by finance or sales opsabout 15 min
Shown because you answered “Someone notices and tells us”; “It depends on the kind of deal, and nobody tracks the unsent ones”.
How to check, and why it happens
The deal carries a company name and an email but not a full billing address or tax details. The first invoice cannot be finalised, or goes out without tax, until someone fills the gap.
Why it happens. Sales tools often hold only what the rep needed to close; in some billing tools an incomplete address stops the invoice, and a missing tax registration gives no error, so a zero-tax invoice is not proof the setup is right.
Usually fixed by: Finance operations, with sales operations (which fields are required on the deal).
Kind of break, one of six: Field landed: did each field arrive with a value, in the right place? Arrival: did it show up in the next tool in time?
Sources: Vendor documentation
Show more (1)
4. One customer becomes two (or more) customers in billing
Worth a quick lookCustomerRun by finance or sales opsabout 15 min
Shown because you answered “Automatically, and nobody checks”.
How to check, and why it happens
The same customer has two records in your billing tool, each with its own payment method, subscriptions and invoices. Payments, credits and renewals are split between them, and the CRM points at only one.
Why it happens. The hand-off creates a new billing customer each time it runs (a retry after a timeout, a second deal, a checkout link) instead of first looking for an existing one by a stored ID. In some tools two customers cannot be merged afterwards.
Usually fixed by: Finance operations, with whoever maintains the connection.
Kind of break, one of six: Condition: does a rule that should always hold, hold?
Sources: Vendor documentation · Vendor documentation
The common questions follow six kinds of check: Arrival (did it show up in the next tool in time?), Return path (does what the next tool did get back to the first?), Count (do the numbers at each end agree?), Freshness (is the step still running, and on time?), Field landed (did each field arrive with a value, in the right place?), Condition (does a rule that should always hold, hold?).
Checking by hand does not last
Everything above is a one-off look. The breaks that cost you are the ones that start next Tuesday, when someone changes a field.
No sign-up was needed for this page and nothing you chose was saved. Print this page to keep it. Start again.