Automated project invoicing: Fixed prices contracts
After assessing the most commonly used time & material contract types, that we went through in [Part 1] and [Part 2], we now go through fixed price contract types.
Typical fixed-price contracts are based on a fixed price agreed with the customer, which is used for invoicing when the purchased service/product is delivered or during the project.
The first invoicing type is Invoicing based on a payment plan with revenue recognition per project, a so-called Fixed price standard contract.
Invoicing based on a payment plan with per-project revenue recognition
This contract type is used for typical fixed-price deliveries, where the customer pays a fixed amount for delivery, for example according to a multiple-payment plan.
What are the pros and cons with invoicing based on a payment plan with per-project revenue recognition?
For fixed-price projects, the supplier carries the risk of budget overruns but, conversely, the supplier is able to achieve high hourly rates and contribution margins through effective project management.
Selling every product or service at a fixed price can be tempting, as it requires less administration and invoicing. On the other hand, it can be an unfortunate shortcut, as it poses increased challenges in terms of managing accounts, work in progress and the bottom line in general.
The challenges peak at long-term fixed-price projects, where revenue recognition is expected to follow performance. In other words, there is a need to continuously make a so-called completion level assessment for calculating turnover.
For example, in the case of major deliveries many companies prefer to invoice the customer on an ongoing basis: 40% of the contract total in advance, 50% after the first major delivery and 10% upon final delivery.
Invoicing based on a payment plan with per-task revenue recognition
Some companies are particularly demanding when it comes to the level of detail in revenue recognition and invoicing. As such, viewing each project as a financial unit is insufficient.
This may be because every single task of a project has its own separate payment, which is released for invoicing as soon as the task is finished. It may also be due to in-house procedures, revenue budgets (and bonuses) for individual departments, teams or employees.
In these cases, dividing a project in a clearly defined and infrangible revenue framework might be prudent. This is particularly interesting if payments for the individual sections of a contract are determined by the delivery.
Example: a company who offers monthly salary management based on the number of payslips processed and supply consultancy at a fixed price per month. The easiest solution here is to group everything in one project and one contract while controlling the invoiced value for payslip processing only flows to work carried out on the payslip task.
By controlling the revenue recognition per subtasks (payslips and counseling), the company can always see the contribution margin on the different tasks within the same fixed price contract. Is it on the administration of payslips or the counseling you earn most money?
This is the advanced management of fixed-price contracts compared to the "normal" standard agreement described earlier. Please consider if it is necessary for you to separate the value on the different subtask.
