Business Central Projects: The Percentage of Completion (POC) WIP Method Scenario
- Ken Sebahar
- Jul 17
- 11 min read
Updated: Oct 9
In this post, we take a deep dive into the sea of Project WIP Method usage. Since the Percentage of Completion (POC) WIP Method is commonly used, we will walk through a full project life cycle scenario showing how the WIP Method field is used to calculate and post revenue and expenses against Projects. But before we begin, let’s do a quick review of WIP Methods in Business Central and how they are designed to work.
Note: This related post will also help with gaining a basic understanding of WIP Methods: Business Central Projects: Understanding WIP Methods.
WIP Method Setup
Business Central offers multiple standard WIP Methods. Each WIP Method provides a different method for determining how the system will recognize Project revenue (sales) and costs.
Note: The standard WIP Method Codes defined within Business Central assume that WIP and Recognition entries should be calculated for both Sales and Cost; however, a custom WIP Method Code can be created where WIP and Recognition values are only calculated and posted for either Sales or Costs.
The “Recognized Cost” and “Recognized Sales” fields on the WIP Method setup record is used to determine the specific calculations that will be applied to determine how much of a project’s billed amounts and/or incurred costs should be placed on the balance sheet and how much should be included on the periodic income statement. There are different options available for each of these fields with the combination of selections used to provide the desired result for revenue and cost recognition.
Understanding how these calculations work can be tricky, especially in a large project with various types of expenses or a high volume of activity within each period. In an effort to demystify these calculations, let’s walk through an entire project lifecycle to demonstrate how the system is calculating the WIP and Recognition values.
As mentioned, this example will utilize the standard “POC” or “Percentage of Completion” WIP Method Code. Based on the popularity and feedback on this post, additional posts may be created covering some of the other WIP Methods.
Percentage of Completion (POC) Model Overview
Under a percentage of completion recognition model (not specific to Business Central, but generally speaking), a budget is defined for the Project that estimates the total revenue and costs to be incurred. Then, as costs are incurred, they are recognized on the income statement in the period incurred. This side of the equation is relatively straight-forward. Then, the Project’s cost budget is compared against the actual costs incurred on the Project to-date to calculate the percentage of total costs that have been incurred life-to-date on the Project (referred to as the “Percent Complete”). This calculated percentage is then applied to the sales side of the Project to ensure that the same percentage of the Project’s sales budget has been recognized on the income statement. Any difference between this percentage and what has been invoiced to the customer is then placed on the balance sheet (typically as either “Unbilled Receivables” or “Deferred Revenue”).
In this model, the Project’s budget (both sales and costs) plays a key role in determining how much sales will be recognized in each period. If budgeted sales and costs are not available, then the percentage of completion WIP method cannot be used – in Business Central or any other system! With that said, it is common that the exact sales and costs on a Project are not known at the start of a Project; therefore, reasonable estimates are allowed (required) in order to accurately calculate the percentage of the Project that has been completed to date.
Scenario assumptions:
To keep this example as simple as possible, some assumptions we will apply include:
We will use a single project
We will complete a single transaction each month just to make it perfectly clear how the
WIP values are being calculated (and posted to the General Ledger).
The project will have only one Project Task.
We will use round numbers so that the math is clear and easy to follow.
There are fields on the Project Task record (WIP-Total, Project Posting Group) as well as fields on the Project Setup page that can impact how WIP values are calculated, but application of these fields is a more advanced topic that will not be considered here.
Scenario: Cronus USA, Inc. has been hired by Business Central Brewery to help develop and produce a new Cold Lager beer which Business Central Brewery will offer at their brewpubs.
The primary costs to be incurred on this project include:
Labor – various types of labor including recipe creation, brewing of multiple test batches, marketing design, and testing with the client’s focus group.
Materials – the ingredients to brew the beer, as well as bottling, labels, and other packaging.
Freight – shipping the test batches to the client
Business Central Brewery has agreed to pay a total of $10,000 for this project as follows:
40% will be invoiced up-front when the project begins
40% will be invoiced upon delivery of the first test batch
20% will be invoiced upon final delivery of the final test batch (closure of the project).
Based on the above information, below is the initial project and budget setup in Business Central.
As you can see below, Cronus USA, Inc. expects to make $4,000 in profit on this project, or 40% of the planned $10,000 in customer billing:
January
Billing: A Sales Invoice is generated and delivered to Business Central Brewery for $4,000.00.
Cost: No costs are incurred.
Budget: the initial budget was set with an expected profit of $4,000.00 or 40%.
At the end of January, the Task line reflects that $4,000.00 has been invoiced. Also, on the Posting tab, the “% Invoiced” field shows that 40% of the estimated sales have been invoiced, while the “% Completed” field shows that the Project is 0% completed ($0 costs have been incurred):
The Calculate WIP process is run at the end of the January, which yields the following results.
Note: This process calculates the values but a separate process called “Post WIP to G/L” is used to post the values to the General Ledger. The separation of the calculation and posting of the WIP values provides users with the opportunity to review the calculated values and make adjustments to the Project entries, thereby minimizing the number of G/L Entries created.
To determine the net amount to be posted to the G/L each period, the “To Post” fields should be compared to the “Posted” column. In this case, because no “WIP Sales” value has previously been posted, the entire $4000.00 that was invoiced to the customer will be posted into the “WIP Sales” (i.e. Deferred Revenue) account when the “Post WIP to G/L” process is run.
It is important to mention here that the system does not simply post a net adjustment amount to each of the Project-related G/L Accounts. Instead, for each period, the previous period entries are reversed and the new period values are posted (usually all with the same Posting Date). This method results in more G/L Entries, but it is this logic and structure that allows Project WIP to be reconciled for all historical periods – a very welcomed feature when the auditors arrive and ask for verification on what makes up the Project WIP values on the balance sheet as of the end of last year.
After posting the entries, the values in the “To Post” left side of the page will now be reflected in the “Posted” right side of the page:
February
Billing: No Sales Invoice is generated.
Cost: 30 hours of labor are incurred for product development (Project Journals are posted for 30 hours at $50.00/hour, or $1,500.00 in costs).
Budget: no changes were applied to the project budget.
At the end of February, the Task line now reflects that $1,500.00 in costs have been incurred. Therefore, the “% Completed” field shows that the Project is now 25% completed:
The Calculate WIP process run at the end of February yields the following results:
Again, to determine the net period adjustment to each G/L Account, the values on the “To Post” section should be compared to the “Posted” values. In this case, “WIP Sales” will be reduced from $4,000.00 to $1,500.00 while “Recognized Costs” will have $1,500.00 posted. Additionally, $2,500.00 in “Recognized Sales” (revenue) will also be posted. The revenue recognition has increased because the project is now 25% complete (based on the $1,500.00 in incurred cost relative to the total estimated Project cost of $6,000.00). The remaining balance of the previous $4,000.00 invoice will remain in “WIP Sales” (or deferred revenue).
The values on the right side of the WIP and Recognition fast tab (above) continue to show the values that were posted effective the end of the last period. However, after posting the February entries, the values in the “To Post” left side of the page will be reflected in the “Posted” right side of the page:
March
Billing: No Sales Invoice is generated.
Cost: an additional 60 hours of labor are incurred for product development and manufacturing of the initial batch (Project Journals are posted for 60 hours at $50.00/hour, or $3,000.00 in costs).
Budget: no changes were applied to the project budget.
At the end of March, the Task line now reflects that $4,500.00 in costs have been incurred. Therefore, the “% Completed” field shows that the Project is now 75% completed:
The Calculate WIP process run at the end of March yields the following results:
Now it is getting interesting! The Project is now 75% complete since $4,500.00 of the estimated $6,000.00 costs have been incurred. On the cost side, we will continue to recognize costs in the period the costs were incurred, or $3,000.00 for March. However, we have only billed 40% of the Project while the Project is 75% complete, so the system needs to make sure that $7,500.00 in revenue has been recognized. So “Recognized Revenue” will be increased and “WIP Sales” will be decreased (resulting in a negative value, which effectively results in unbilled receivables on the balance sheet instead of deferred revenue) by $5,000.00.
After posting the WIP Entries:
April
Billing: The second planned Sales Invoice for $4,000.00 is generated upon delivery of the first test batch of the new beer.
Cost: No additional costs were posted.
Budget: no changes were applied to the project budget.
The Calculate WIP process run at the end of April yields the following results:
At the end of April, the Project remains at 75% complete (since no additional Project costs were incurred) so there is no change to the “Recognized Costs” or “Recognized Sales”. However, since a total of $8,000.00 has now been invoiced but only $7,500.00 in revenue is recognized, the “WIP Sales” is adjusted to $500.00.
After posting the WIP Entries:
May
Sales: No Sales Invoices is generated.
Cost: No additional costs were applied to the Project.
Budget Change: Upon delivery of the test batch to Business Central Brewery, an issue was found which resulted in the decision by Cronus USA, Inc. to produce an additional test batch of Cold Lager for no additional charge to the client. The result of this change is expected to require an additional 24 hours of labor.
A new Project Planning Line was added to reflect the additional 24 hours on the project budget.
This budget change automatically recalculated the “% Complete” field from 75% down to 62.5%.
The Calculate WIP process run at the end of May yields the following results:
Recognized Costs have not changed. However, since the Project is now only 62.5% complete instead of 75% complete at the end of April (due to the additional expected costs), the “Recognized Sales” has been decreased by $1,250.00 during May and “WIP Sales” (deferred revenue) is increased.
Note: This example demonstrates the importance of the Project budget in determining the amount of revenue to be recognized in each period. The Project budget must be monitored and updated each period as needed (up or down) to reflect the current project expectations for total costs.
Note: Because of the impact of budget changes on periodic profitability, the Field Monitoring or Change Log tool should be considered for use to track modifications to the Project Planning Line “Quantity” and “Unit Cost” fields. This will provide an audit trail showing the date/time and user who made changes to Project budget lines.
June
Sales: The final Sales Invoice for $2,000.00 is generated.
Cost: The remainder of the incurred costs were applied.
Budget Change: no changes were applied to the project budget.
We will make an exception here and post both billing and costs to the Project during June. Therefore, at the end of June, all project costs are posted and all invoices have been generated.
As you can see above, even though the Project tasks have been completed, there is still a difference between the budgeted costs ($7,200.00) and the actual costs ($6,840.00). This is a good thing because it means that the Project was completed more efficiently and profitability than expected.
The Calculate WIP process run at the end of June yields the following results:
You likely notice that even though the Project work is done, there is still $500.00 that has not yet been recognized (remains in “WIP Sales”, or deferred revenue). This is because the Project “Status” has not yet been changed to “Completed”. As long as the Project remains “Open”, additional costs (or billing) can continue to be posted to the Project. The Project will remain “Open” as of the end of June and these WIP values will be posted.
July
No additional Project transactions are applied
The Project Status will be changed from “Open” to “Completed” (indicating that the final sales and cost amounts have been posted and no further changes will be made to the Project)
Note: It is very important to set the “Ending Date” to the current period when changing the Status of the Project to “Completed” to ensure that the closing entries are properly generated.
The results of the final Calculate WIP process (any time during July):
This final WIP calculation process ensures that:
1) No remaining values remain in “WIP Sales” (or “WIP Costs”)
2) The final cost amount will be used to determine “Recognized Costs”
3) The final invoiced amount will be used to determine “Recognized Sales”
After posting the final WIP Entries:
The Completed Project will remain available within Business Central to review for future reference, reporting, or copying.
Note: At the completion of the Project or at any point during the Project, the Project can be archived so that snapshots of the Projects throughout the Project’s life cycle can be reviewed to analyze changes to the project over time.
While this post used the POC (Percentage of Completion) WIP Method to demonstrate how WIP values are calculated, the general process to calculate and post WIP is the same for other WIP Methods (just with different values being calculated).
For additional details on the calculations used on the other WIP Methods, this article from Microsoft Learn is a good resource for understanding the specific calculations associated with each method: Microsoft Learn: Understanding WIP Methods in project management.
Once you have mastered the use of WIP Methods and verified the specific WIP Method(s) to be used within your organization, the final step is to understand how the various Posting Groups and G/L Accounts should be used when setting up Projects, Items, Customers, and Resources so that all of the Project-related G/L Entries result in a beautiful and easy-to-understand set of financial statements for all internal and external stakeholders. But this is a complicated topic and after what we just went through here, G/L Entry flow is definitely a task for another day!