Having learned that there is no straightforward way to handle advance
payments/open credits when using the "Customer:Job" function within
Quickbooks, we've decided to just drop the use of the "Jobs" altogether and
just make invoices using the "Customer" A/R account. In the interest of
being able to locate invoices for a particular job, I'm trying to devise a
way to put something on the invoice so that invoices for a particular job
can be located if necessary. I thought of changing the invoice number
manually, but that isn't great from a control point of view. Another
choice that seems to work is to use the PO field. Not many of our
customers use the PO so I'm thinking we could put our internal Job # in
this field. And for customers who do use PO's, the field appears to be
long enough to enter that info also.
Before going ahead with this, I thought I'd consult the Group Mind here and
see if anyone has a better suggestion or even an alternate method for
handling the problem?
I've always used, and have turned many others onto this method, an
abbreviated job prefix on the bill number line.
An example would be a house being built for XYZ at 12 Something Street. A
bill from a vendor with an invoice number of 11769 would look like this:
The above tells me the job first and the bill/invoice number second. No
vendor has ever complained of this method since their invoice number is
still clearly identifiable thanks to the hyphen.
I believe you posted you were using contractor edition. One of the
advantages to contractor edition is the ability to use estimates and
progress invoicing. You will not be able to do that if you do not use jobs.
As for the advance payments.. just be sure that when payments arrive they
are posted (using the recieve payments window) to the correct job.
If you do not wish to keep track that way, you can, alternately, post ALL
payments to the parent customer record. All open invoices will show under
the parent, and all payments on the parent level can be applied to any open
invoice. The main disadvantage to this is reporting. Payments will show at
the parent level, and not at the job level, although the balance at the job
level will be correct.
The sticky part is with credits. If, however, you create a progress invoice
at the time you request a deposit (you can keep it internal if you wish) you
can apply the job deposit to the progress invoice, avoiding credits
Not using the Contractor's Edition and the job function for this company is
not nearly so complex as would be a contractor's. In fact, the more I
think about it, the job function in this particular case was a poor choice
given QB's inability to handle open credits. This is kind of a high-flow
business. Some of the regular, long-time customer do two "jobs" per week,
and there is usually just a single invoice, or a very few at most for each
"job." This has resulted in a really bloated "Customer:Job" list (although
they could just make the jobs inactive when they are done...). But the
main bugaboo is this *insane* (to me :-)) inability of QB to apply advance
payments, or overpayments to any job/invoice you please. They have many
customers who just keep money "on account" to cover their ongoing mailings,
*and* with slight variations in actual postage popping up fairly regularly,
it's also quite common for them to overpay an invoice. Using the job
function in this situation has resulted in lots of extra time apply credits
"via" an extra invoice/credit memo and a suspense account.
I sure am learning a lot though....:-).
Thanks for your input.
So long as the payments are posted at the top level, the payments can be
applied to ANY open customer invoice. There is no need to use extra
invoices, credit memos or suspense accounts.
Even if the original payment was left as a credit, it is possible to edit
that payment, and apply it to new open invoices.
The trick is leaving the payments at the parent level.
But, if you are not using estimates, then I agree wholeheartedly that
setting up jobs for all your invoices will quickly bloat the customer:job
Sounds like you are learning quickly.
BeanSmart.com is a site by and for consumers of financial services and advice. We are not affiliated with any of the banks, financial services or software manufacturers discussed here.
All logos and trade names are the property of their respective owners.
Tax and financial advice you come across on this site is freely given by your peers and professionals on their own time and out of the kindness of their hearts. We can guarantee
neither accuracy of such advice nor its applicability for your situation. Simply put, you are fully responsible for the results of using information from this site in real life situations.