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 connecting your own tools is coming next.
1 check first
1 more
2 check first
1 more
2 check first
1 more
3 also check
1 check first
2 more
2 also check
1. The deal amount is not the total billing is set up to charge
Check firstHandoverRun by finance or sales opsabout 30 min
Shown because you answered “Someone retypes it from the deal or the contract”; “Nobody; the signed document is filed away”.
How to check, and why it happens
The amount on the deal differs from the total of the products, quantities and discounts that billing builds the subscription from. Sales reports show one number, invoices another.
Why it happens. A deal amount can be typed by hand or worked out in different ways (before or after discount, with or without fees and tax), while billing builds from the product lines (our reading).
Usually fixed by: Sales operations (deal amount rules), with finance operations.
Kind of break, one of six: Count: do the numbers at each end agree? Field landed: did each field arrive with a value, in the right place?
Sources: Vendor documentation
2. 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”; “Someone retypes it from the deal or the contract”.
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
3. Billing charges for a different product or price than the deal says
Check firstSubscriptionRun by finance or sales opsabout 30 min
Shown because you answered “Two lists, kept by different people”; “Someone retypes it from the deal or the contract”.
How to check, and why it happens
The product on the deal has no matching item in billing, or matches an old one. The hand-off stops, makes a generic placeholder item, or uses a retired price. A customer can be billed for the wrong thing, or at an old rate, for a long time.
Why it happens. The two product lists are kept by different people, in some tools a price cannot be edited once created (a new one is added), and the link between the lists is a name or code that drifts.
Usually fixed by: Finance operations (billing catalogue), with sales operations (CRM product list).
Kind of break, one of six: Field landed: did each field arrive with a value, in the right place? Condition: does a rule that should always hold, hold?
Sources: Integration vendor guide · Vendor documentation · Vendor documentation
4. A fixed-term deal becomes a subscription with no end, or the wrong end
Check firstSubscriptionRun by finance or sales opsabout 20 min
Shown because you answered “Nobody; the signed document is filed away”; “Someone retypes it from the deal or the contract”.
How to check, and why it happens
The contract runs 12 months, but billing holds a subscription with no end date, so it can keep going after the term, or it ends on a date that does not match the contract. The renewal conversation is never triggered, or comes at the wrong time.
Why it happens. A fixed term needs an explicit end or schedule in billing. In some tools a deal with items of different term lengths cannot become one subscription, and a schedule that finishes leaves the subscription in place.
Usually fixed by: Finance operations, with sales operations (the term field on the deal).
Kind of break, one of six: Field landed: did each field arrive with a value, in the right place? Condition: does a rule that should always hold, hold?
Sources: Vendor documentation · Integration vendor guide
5. Payment and subscription status never get back to the CRM
Check firstPaymentRun by finance or sales opsabout 15 min
Shown because you answered “Sales asks finance when they want to know”; “It doesn't get back”.
How to check, and why it happens
The way back is missing or partial: the first payment is shown but a cancellation is not, or nothing at all. The account stays "closed won" forever, and the CRM cannot show who is active, past due or cancelled.
Why it happens. The return path is a separate setup with its own settings. In some tools the status is only set when the connection is configured for it, and a status built on one payment event misses invoices paid another way (a trial, a credit, a payment recorded outside the tool).
Usually fixed by: CRM admin or sales operations, with finance operations.
Kind of break, one of six: Return path: does what the next tool did get back to the first?
Sources: Vendor documentation · Vendor documentation
6. The signed contract says one thing, the deal and billing say another
Check firstCustomerRun by finance or sales opsabout 30 min
Shown because you answered “Nobody; the signed document is filed away”; “I'm not sure, to: Is there a rule that should always hold (for example, every won deal is invoiced within a set number of days), and does anything check it?”.
How to check, and why it happens
After signature, the price, quantity or term is changed in the CRM or in billing (a discount agreed by email, extra seats), but the signed document is not updated, or the reverse. Three records now disagree, and it surfaces at the first invoice or the renewal.
Why it happens. In some tools a fully signed document is locked, so later changes are made somewhere else, and nothing links the change back to the document (our reading).
Usually fixed by: Finance operations (billing side), with sales operations; the document itself belongs to whoever manages contracts.
Kind of break, one of six: Field landed: did each field arrive with a value, in the right place? Condition: does a rule that should always hold, hold?
Sources: Vendor documentation
Show more (8)
7. An invoice that has gone out differs from the deal and cannot simply be edited
Check firstInvoiceRun by finance or sales opsabout 20 min
Shown because you answered “It doesn't get back”; “Nobody; the signed document is filed away”.
How to check, and why it happens
An issued invoice has an amount, term or detail that differs from the deal. People void it and issue a new one, or issue a credit, so the CRM, the contract and billing now hold different versions. In some countries, rules also apply to how an invoice may be corrected.
Why it happens. Once issued, most of an invoice is locked in some tools, and a correction is a separate document (credit or replacement) that the other tools do not see.
Usually fixed by: Finance operations, with whoever is responsible for accounting (for the rules).
Kind of break, one of six: Return path: does what the next tool did get back to the first? Count: do the numbers at each end agree?
Sources: Vendor documentation · Law or standard
8. A payment fails and the people who own the customer do not know
Check firstPaymentRun by finance or sales opsabout 20 min
Shown because you answered “Sales asks finance when they want to know”; “It doesn't get back”.
How to check, and why it happens
The first or a renewal payment fails and the subscription goes past due, unpaid or cancelled. The account owner sees a healthy customer and does not call; the customer is surprised by a cut-off, or keeps access for free.
Why it happens. Failure is handled inside billing (automatic retries, then a setting that decides what happens), and the CRM learns of it only if a status is sent back (our reading).
Usually fixed by: Finance operations (collections), with sales or customer-success operations (visibility to account owners).
Kind of break, one of six: Return path: does what the next tool did get back to the first?
Sources: Vendor documentation
9. An upsell, cut or cancellation is recorded in only one system
Check firstChangesRun by finance or sales opsabout 30 min
Shown because you answered “Directly in billing; the CRM is updated later, if at all”; “It doesn't get back”.
How to check, and why it happens
A change is recorded in the CRM but not in billing, or the reverse, or a change made directly in billing is later undone by a step scheduled at signing. The customer is billed the old amount, or the CRM counts revenue that no longer exists.
Why it happens. Changes travel only when someone re-sends the deal or uses the intended path, and in some tools direct edits can be overwritten by what was scheduled earlier.
Usually fixed by: Sales operations (change process), with finance operations.
Kind of break, one of six: Return path: does what the next tool did get back to the first? Count: do the numbers at each end agree?
Sources: Integration vendor guide · Vendor documentation
10. 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”; “Someone retypes it from the deal or the contract”.
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
11. The invoice total is slightly off the deal, or in another currency
Check firstInvoiceRun by finance or sales opsabout 20 min
Shown because you answered “I'm not sure, to: How often does someone compare closed deals in the CRM with customers and subscriptions in billing?”; “Nobody; the signed document is filed away”.
How to check, and why it happens
The invoice total differs from the deal or contract by a few cents, or by a whole unit in a currency without cents. Occasionally the invoice is in a different currency than the contract, or an amount is out by a factor of 100. Small gaps eat time and the big one is easy to miss among them.
Why it happens. Tools round at different points (per line, per invoice, tax on its own), currencies have different smallest units, and in some tools one price can exist in several currencies with a default used when none is passed.
Usually fixed by: Finance operations.
Kind of break, one of six: Count: do the numbers at each end agree? Field landed: did each field arrive with a value, in the right place?
Sources: Vendor documentation · Vendor documentation
12. The first invoice is created but never sent
Check firstInvoiceRun by finance or sales opsabout 10 min
Shown because you answered “Someone notices and tells us”; “Finance reviews and sends each one by hand”.
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
13. One customer becomes two (or more) customers in billing
Check firstCustomerRun by finance or sales opsabout 15 min
Shown because you answered “Someone retypes it from the deal or the contract”; “I'm not sure, to: Is there a rule that should always hold (for example, every won deal is invoiced within a set number of days), and does anything check it?”.
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
14. The subscription starts on a different date than the contract
Check firstSubscriptionRun by finance or sales opsabout 15 min
Shown because you answered “Someone retypes it from the deal or the contract”; “Nobody; the signed document is filed away”.
How to check, and why it happens
The subscription starts on the close date, the signature date or the first billing day, not on the contract's start date. The first invoice then has a part-period charge, a charge for past time, or nothing at all, and the customer queries it.
Why it happens. Close date, contract start and billing start are three different dates, and in some tools a part-period first charge is worked out when the start and the billing day do not line up.
Usually fixed by: Finance operations, with sales operations (which date goes on the deal).
Kind of break, one of six: Field landed: did each field arrive with a value, in the right place?
Sources: 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.