I'm after a bit of advice please, I'm trying to get an understanding of how WIP works.
We are a small construction company, our accounts manager records WIP in a way I'm not convinced is correct....but I may be wrong.
Basically whenever we receive an order the accounts manager records it in WIP and the order value goes towards the overall WIP value, each month it is revered then added in again as the value less what was invoiced as an application for payment that month and the purchases in the month added.
As a result our WIP is always really high.
Is this right?
The way i had always understood it was this...
You raise an invoice against a project that is ongoing, or you dont raise an invoice because the works are incomplete, but you have spent money on the works in materials/labour etc, this value that has not been billed yet becomes works in progress.
When it is invoiced the following month it is then reversed in the journals.
And so WIP will be low as in most cases we will nearly always invoice everything in that month.
Am I over or under thinking it or getting it wrong completely?
So the two examples of how we end up with amounts on WIP are as follows (in my opinion):
Example 1:
We start a large project, in the month we spend £500 on materials, £500 on labour, but only invoice £800 in the month, we then record a WIP value of £200 against this project.
Next month we invoice the outstanding £200 and reverse this on WIP.
Example 2:
We start a project in which we spend £100 on materials and £100 on labour in the month, we dont invoice it as it isn't complete, we record a value of £200 on WIP.
Next month we invoice the outstanding £200 and reverse this on WIP.
So in both cases, we would record the WIP value as a sale in the month it was made, when we reverse WIP when we invoice it we deduct this from the sales from the current month as this is movement in the journals as it as already been accounted for as a sale in a previous month.
Would I be on the right track?
I Really do apologise for what is probably a really simple question to some on here.
What your account manager is doing, even if inadvertently, is artificially inflating the company's bottom line and making them look healthier/more profitable than they are.
You are in principle correct about how it should be done in your first post: The WIP value should be the costs incurred on a job that have yet to be covered through the sales (invoice or application for payment).
Your two examples are slightly iffy, because they seem to assume the sales amount is the same as the cost amount - but, as I said, the principle is correct.
The problem, really, is deciding which costs incurred so far are covered by a sales invoice, and to exclude those from your WIP, and include what's left. How you go about this depends on a number of factors - such as the size of the business and the volume of date/information you have to work with, the software being used, and so on.
Edit: As an afterthought, I've just remembered an example that I documented some years ago: http://posts.softrock.co.uk/2009/11/obtaining-a-work-in-progress-figure-from-sage-job-costings/
Obviously, that's specific to Sage/Sage Job Costings - but it might hopefully offer some ideas. It doesn't cover partially invoiced jobs, a problem that didn't occur to me initially, but which I then added an approach for.
How I did that was to add another classificiation - IIRC, just "0000 - partially invoiced". When I needed the WIP figures, I ran the reports as described in that article, then separately established which jobs were classified as partially invoiced. For each of those jobs, I looked at the date of the most recent invoice, then ran a report on the job itself, establishing all costs incurred since the date of the invoice, and added that to the WIP figure from the main report.
HTH.
-- Edited by VinceH on Friday 13th of November 2015 10:51:13 AM
-- Edited by VinceH on Friday 13th of November 2015 10:52:16 AM
__________________
Vince M Hudd - Soft Rock Software
(I only came here looking for fellow apiarists...)
What your account manager is doing, even if inadvertently, is artificially inflating the company's bottom line and making them look healthier/more profitable than they are.
You are in principle correct about how it should be done in your first post: The WIP value should be the costs incurred on a job that have yet to be covered through the sales (invoice or application for payment).
Your two examples are slightly iffy, because they seem to assume the sales amount is the same as the cost amount - but, as I said, the principle is correct.
The problem, really, is deciding which costs incurred so far are covered by a sales invoice, and to exclude those from your WIP, and include what's left. How you go about this depends on a number of factors - such as the size of the business and the volume of date/information you have to work with, the software being used, and so on.
Edit: As an afterthought, I've just remembered an example that I documented some years ago: http://posts.softrock.co.uk/2009/11/obtaining-a-work-in-progress-figure-from-sage-job-costings/
Obviously, that's specific to Sage/Sage Job Costings - but it might hopefully offer some ideas. It doesn't cover partially invoiced jobs, a problem that didn't occur to me initially, but which I then added an approach for.
How I did that was to add another classificiation - IIRC, just "0000 - partially invoiced". When I needed the WIP figures, I ran the reports as described in that article, then separately established which jobs were classified as partially invoiced. For each of those jobs, I looked at the date of the most recent invoice, then ran a report on the job itself, establishing all costs incurred since the date of the invoice, and added that to the WIP figure from the main report.
HTH.
-- Edited by VinceH on Friday 13th of November 2015 10:51:13 AM
-- Edited by VinceH on Friday 13th of November 2015 10:52:16 AM
Vince
That is excellent thanks, apologies my examples are a bit poor, from a bit of research and your comments I assume that what should get recorded on WIP is purely the value at raw cost, not the value at which we will record the sale.
In principal we should be invoicing as much as possible and the WIP should remain low, I assume that some companies would or could use this to, as you say over inflate the companies bottom line.
"from a bit of research and your comments I assume that what should get recorded on WIP is purely the value at raw cost, not the value at which we will record the sale."
Correct - but don't forget that labour is one of those costs.
__________________
Vince M Hudd - Soft Rock Software
(I only came here looking for fellow apiarists...)
You are correct - as Vince says WIP is the net value of costs/labour/etc that have not yet been invoiced out. What you are doing by adjusting for WIP is deferring the cost, so that it matches the period in which the sale falls, so that the correct profit for that period is picked up. An order is simply a request for work, no work has been done. The payment application seeks to value work done, and request money.
I work for a construction company, and I post the payment applications into the software, but in a way that means they don't affect the profit and loss. When a self bill comes in, I then adjust the payment application amount, and post a "real" sales invoice. I also do project costings. This allows my client to see what has been applied for via payment application, what has been received against it, and, the cost of the project so far.
At the year end, the accountant uses the balance on the payment applications account to determine WIP, when reviewing with the client. I imagine the costings are also reviewed alongside.
You are correct - as Vince says WIP is the net value of costs/labour/etc that have not yet been invoiced out. What you are doing by adjusting for WIP is deferring the cost, so that it matches the period in which the sale falls, so that the correct profit for that period is picked up. An order is simply a request for work, no work has been done. The payment application seeks to value work done, and request money.
I work for a construction company, and I post the payment applications into the software, but in a way that means they don't affect the profit and loss. When a self bill comes in, I then adjust the payment application amount, and post a "real" sales invoice. I also do project costings. This allows my client to see what has been applied for via payment application, what has been received against it, and, the cost of the project so far.
At the year end, the accountant uses the balance on the payment applications account to determine WIP, when reviewing with the client. I imagine the costings are also reviewed alongside.
Hi Michelle,
Thanks for your input, this exactly what I have started doing, I create a job costing spreadsheet in which I record what has been applied for that month, and what has been debited and if the debited value is larger than the credit value I assume this value is WIP?
I Would be really interested to hear how you deal with your payment applications, again my understanding is that we issue a payment application, we then receive a payment notice (self billing) and then issue a VAT invoice.
However our accounts manager has being doing this very differently, the application is being raised, and a VAT invoice raised at the same time and sent with the application, if a pay less notice comes back (self billing at less than what we applied for) the invoice is then credited and re-submitted.
We have also been raising a VAT invoice for the retention relating to that payment application at the same time, the retention is normally around 5% of the contract value with 2.5% released upon completion and the last 2.5% released after 12 months, and so we are paying VAT on invoices for which we won't receive payment for over a year!
I Have questioned this but been told that we need to do it this way as otherwise we wouldn't be able to post the sales from the applications for that period and so would reflect a loss?
Hi ??? (please add you first name into your signature for us)
If you have the right version of sage, it will do your costings for you. Do you have Accounts 50 or Instant? If you have project capability, you should see it on the task bar to the left.
I set up 3+ customer accounts -
Company A - Sales invoices Company A - Retentions Company A - Payment applications - Project 1 Company A - Payment applications - Project 2
Where a customer has multiple projects on the go, I create a payment application customer account for each job. Note that the retentions and payment application customer accounts, are just dummy accounts used to monitor what is going on.
On the balance sheet, I have the debtors control account - 1100 as normal
I have 1101 as the main payment applications code, and this is usually not used, as I create sub-codes for each job
110101 will be Customer A - payment applications - Project 1 (insert project name here, rather than a number, of course) 110102 will be Customer A - payment applications - Project 2 110103 might be Customer B - payment applications - Project 3 110104 might be Customer B - payment applications - Project 4 110105 might be Customer C - payment applications - Project 5
I have 1102 as the main retentions code, and again this doesn't get used, as I create sub-codes for each customer. Instead of having codes per project, I just use the details section to say which project and valuation number it is, but you could create a code per project, much like the payment applications code.
110201 will be Customer A - retentions 110202 will be Customer B - retentions 110203 will be Customer C - retentions
What the above gives you, is some idea of what retentions are in existence, and shows you the difference between your payment applications to the self bills. Its just a management tool, which saves you having to use spreadsheets etc, and it also allows the accountant to see what has been going on. These values have no effect on the profit and loss.
I post the payment application as a T9 sales invoice, net of retention, using the date on the PA - there's no VAT on the payment application, only the self bill. The nominal code it gets posted to, corresponds to the project it relates to. So if I issue company A with a PA for project 1, its a T9 sales invoice to customer account "Customer A - Payment Applications - Project 1" and the nominal code will be "110101 - Customer A - payment applications - Project 1". I use the details section to say "Project 1, V1" which is valuation 1. All PAs have a reference number, so I can see if any haven't been sent over by the client. They are separate from the sales invoice numbers.
Your customer account balance should always equal the balance sheet nominal code. What this does is creates a debit balance on 1100 but also a credit on 110101 - which the accountant can then net off, when he posts into his accounts production software, so that debtors is really only balance of the actual sales invoice debtors.
When the self bill comes in, I post a T9 credit note to "Company A - payment applications - Project 1" for the self bill net before retention. I put in the details "Project 1, P1" which is payment 1. This then shows you any difference between what you apply for, and what you receive. The reference will be the same as the sales invoice number you give the self bill. This allows you to match things up, if you need to look back at any point.
Then I post the self bill as a sales invoice, using the next sales invoice reference number, as follows -
Customer A - sales invoice - net value after retention plus VAT. Details are "Project 1, P1" - the net goes to the relevant 4000 code, as now we actually have a sale. Customer A - retentions - as T9 invoice to 110201, again with details "Project 1, P1"
Again, the accountant can net off the 110201 against 1100 when they post into the accounts production package. I write the number on the self bill and file it along with the other sales invoices.
When the retention is eventually paid, I create a T9 credit note to "Customer A - Retentions" for the net value that has been received. This will go to code 110201
I then post a sales invoice to "Customer A - sales invoices" for the net retention plus VAT. It will go to a 4000 nominal code. I have 4000 as sales, and 4001 as retentions released. The accountant will just combine these when they do the accounts.
That's how I deal with self bills. I am of the understanding that sales invoices should not be issue to the customer, if they prepare a self bill - they should only get a payment application. Same for when retention release is requested. The self bill document then becomes a sales invoice when received.
Hope this helps
-- Edited by FoxAccountancyServices on Tuesday 17th of November 2015 02:09:57 PM
PS.. your project costing is very different to the tally of payment applications issued to received... payment applications seek to get the profit in, whereas costings are just costs with no profit. They allow you to see what you are making on the job, when compared to the payment applications/sales invoices
PPS - sorry, don't know why I think you have Sage! If you are using a software package, it might be implementable.. depends on the package. I can only support Sage 50 on that one!
Thanks for your detailed reply, we use a package called Accounts Edge by Mamut.
I Think I get what you mean!
For each client you create a code in the accounts package.
You then have a code for payment applications.
And then each project becomes a sub code? but would you not end up with thousands of codes, would this not get messy?
And also I note that you setup just one rejections account for each client, but how do you then keep track of which retention belongs to which job? and also we normally apply for 2.5% retention back upon completion of the job and the outstanding 2.5% when the defect period has ended normally after 12 months, so in this case would you credit all the retention invoices for this project upon completion, and issue an invoice for the 2.5% then post the other 2.5% retention back to the retentions code to be credited and invoiced in 12 months time?
You say the retentions don't have an effect on the P&L are they not considered as sales in the month? as they do relate to works completed? do you mean that none of the Payment applications have an effect on the P&L until you receive a self bill/payment notice? as this is normally a month after the application?
The only concern I would have is we would end up with a lot of codes as we complete around 100 projects per year which are under payment application.
Thanks for your detailed reply, we use a package called Accounts Edge by Mamut.
You're very welcome. I haven't heard of that software.
I Think I get what you mean!
For each client you create a code in the accounts package.
You then have a code for payment applications.
And then each project becomes a sub code? but would you not end up with thousands of codes, would this not get messy?
Sub coding means you can have up to 99 projects (you can actually make it 1000, with a different set up). Only large contracts, some of which can last a couple of years, get payment applications, in the company I assist. General invoices just go into debtors/sales as normal. When a project ends, and the retention is released in full, the balance sheet code can be renamed for a new project.
And also I note that you setup just one rejections account for each client, but how do you then keep track of which retention belongs to which job?
I use the narrative/details box in Sage to say project name and payment number, which the retention has been taken on.
The credit is also posted with the reference of the sales invoice/self bill, so it can be matched.
Our payment application ref PA85 could be Valuation 1 for Customer A. We then receive a self bill sales invoice, which the contractor shows as Payment 1, for that project. I give this the next available sales invoice number, and file it along with our other sales invoices - lets say that's invoice 2396. I post the T9 credit through the PA customer account, reference = 2396 and details = project name and payment number.
Dead easy to match up. But as I said, you could set up retentions much like the payment applications.
and also we normally apply for 2.5% retention back upon completion of the job and the outstanding 2.5% when the defect period has ended normally after 12 months, so in this case would you credit all the retention invoices for this project upon completion, and issue an invoice for the 2.5% then post the other 2.5% retention back to the retentions code to be credited and invoiced in 12 months time.
You only credit the net retention you receive. So, let's say you had £100 retention taken over the life of the contract - £25 on Payment 1, £25 on P2, £25 on P3, and £25 on P4 (you wish, eh!). You will have created 4 dummy T9 invoices for the retention, and these will equal £100. 12 months after the contract has finished, you can see that the £100 is now 12 months old, using a debtors report that just picks up retention customer codes... this alerts you to send a payment application for 50% of the retention (or just call the contractor and say "eh where's me money!!")
When the extra 50% comes in, you post another T9 credit and re-issue as a sales invoice that picks up the VAT. The self bill for this becomes the sales invoice on your file.
You say the retentions don't have an effect on the P&L are they not considered as sales in the month? as they do relate to works completed?
Per HMRC BIM51520:
In their accounts, builders will generally deal with retentions in one of the following ways:
include retentions within turnover, provide for the estimated cost of remedial work, and make provision for any debt impairment (see BIM42700 onwards), or
defer recognition of retentions until their receipt becomes virtually certain.
Each of the above accords with generally accepted accounting practice and should be followed for tax purposes unless an unrealistically conservative view has been taken.
Its administratively easier to leave a retention debtor, than to estimated the cost of remedial work, and sometime retentions are not recovered, so you are accounting for an uncertain profit throughout the year.
do you mean that none of the Payment applications have an effect on the P&L until you receive a self bill/payment notice? as this is normally a month after the application?
Yes. The self bill date is the tax date. You can post PA's to the profit and loss, and reverse out as the sales invoice comes in, if you wish. The previous bookkeeper wasn't even posting PAs into Sage at all, so they are used to seeing profit before PA anyway. The PA shows as a debtor, so they now its due.
The only concern I would have is we would end up with a lot of codes as we complete around 100 projects per year which are under payment application.
Yep, I am used to working with lots of codes! The number of codes shouldn't matter, if you are getting value from the reports they allow you to create. If your software system is using a number code system, you would have a code range that was specific to "retentions" and "payment applications". So you would type in the first couple of numbers, and that should bring up a list of codes available in that range, with the code name... if you are using names, you should be able to start typing "payment application", and again, it comes up with the range, allowing you to arrow down to the exact code you need. If you software has capability you can also set up defaults
The upshot is, there are a lot of different ways to structure a system.. I've never create two that are the same! The coding build is very geared towards the reports. Sage has a number of functions that take a lot of work out of posting... I train my clients in any that apply, and I just go in once a month to do the management reports, and check everything is running ok, and develop anything necessary. I imagine any decent software has the same capabilities if you really look into it. Most people I meet only use about 15% of what Sage is capable of doing, for instance... and I probably only use about 50% of it.. !!
