
•
•

Summarize blog with








Whether you’re a small startup or a large enterprise, invoicing is crucial to maintaining positive cash flow for your business. But, when to send an invoice to your customers can be a touchy subject for many businesses.
Do you need to start invoicing before or after the deal is closed or after the implementation is complete? What happens if your project scope changes after you’ve started? Do you need to change your pricing depending on the changes?
These situations can be challenging, lead to misunderstandings and confusion, and can ultimately delay the payment. Here are some suggestions to help you with your invoicing strategy.
For the mid-market and enterprise-focused companies that need implementation, revenue recognition happens when the customer can “use their services” or when the “service is delivered”. This happens after the go-live phase. Check the “ASC 606” revenue recognition standard to know more about this. But this shouldn’t stop you from collecting the payment once the contract is signed.
Check with your finance team on how invoicing works. The invoicing period may depend on when you will recognize the revenues, but the invoice itself can be raised immediately and payments collected. This ensures your customers are motivated to start earlier as they have now paid, and there should be some expiry of your obligation to implement beyond a point.
To address deployment delays by clients, use the following options:
Ideally, start the ARR clock when the deal is closed and have the customer implementation fee invoiced at 50% of the deal. This is how I usually lay them out:
Initial 50% paid on the effective date and the remaining 50% as outlined in the schedule below:
It’s better to have a standard customer onboarding plan that lists the dependencies and acceptance clauses unrelated to going live.
You should be scoping the project with your implementation team to see what delays could arise for enterprise customers. From there, you add them to your SOW. You can protect against with language in the SOW.
Also, specify a review period, say, five days, and they are deemed accepted when the period expires unless the client provides proper feedback. This may seem like a lot of structure and process, but it is required once you start getting enterprise customers.
It’s recommended to have a lightweight business requirement document added to the SOW, outlining the exact scope of the implementation for the enterprise. These need to be fleshed out in the presales phase.
Read more: Packaging your services and creating the right offering for your customers
If you’ve any additional strategies you want to share, we’d love to have you join Preflight Community and share it with our members!
“Speeds up CSV importing and saves me from having to get customers to use a template file or create mapped data exports. Quick to integrate and flexible outside the happy path. We found defining workbooks and templates confusing; at a prior job it was configured through code, which I preferred.”
Source: G2 review


AI that executes your delivery work (Add to any plan)
Most popular
Ideal for expanding organizations needing more in-depth capabilities and integration for scaling.
Most popular
Great for teams desiring tailored workflows with comprehensive reporting capabilities.
Most popular
Tailored for large enterprises requiring a fully customizable, comprehensive delivery engine.

A Forward Deployed Engineer (FDE) embeds in the customer environment to implement, customize, and operationalize complex products. They unblock integrations, fix data issues, adapt workflows, and bridge engineering gaps — accelerating onboarding, adoption, and customer value far beyond traditional post-sales roles.





70–85% utilization. 94% G2 rating.
One platform does what the entire table above tries
to split across tools.
70–85% utilization. 94% G2 rating.
One platform does what the entire table above tries
to split across tools.

70–85% utilization. 94% G2 rating.
One platform does what the entire table above tries
to split across tools.
Enterprise implementations fail because customers don’t follow the process or provide clean data on time. Most delays are purely “customer-side” issues.
Implementations fail because complex environments need real-time technical problem-solving. FDEs unblock workflows, integrations, and unknown constraints that traditional onboarding teams can’t resolve on their own.
Get a better all-in-one PSA
Get a better all-in-one PSA
Companies that embed engineers directly with customers see significantly higher enterprise retention compared to traditional post-sales models — because embedded engineers uncover “unknowns” that never surface in ticket queues.

VP Sales, Intercom

A Forward Deployed Engineer (FDE) embeds in the customer environment to implement, customize, and operationalize complex products. They unblock integrations, fix data issues, adapt workflows, and bridge engineering gaps — accelerating onboarding, adoption, and customer value far beyond traditional post-sales roles.






.webp)