Dealing with deposits on invoices

I hired a designer to do some work for me and she required a “mobilisation fee” which was basically just a percentage of the projected cost up front. She estimated $600, and wanted a $60 deposit/mobilisation fee*.

She issued me an invoice for the $60 and I paid it.

When it come to finalisation of the account, she itemised her time and so her invoice is inclusive of all costs (which turned out to be $605). She applied the deposit and I was required to finalise $545.

Now, I suppose I could have just entered the second invoice as $545 and be done with it. Total expenses would have been 545+60=$605 and all would be good in the world. But because she itemised where she spent the time, I recorded it likewise (just for completeness).

However this results in an invoice of $605 that has a credit of $60 on it.

I just created a new line item on the second invoice applying a deposit paid description to it and used a negative 60 for cost. Everything balances out (or so I think) and just because it looks ok, I just want to make sure it actually IS ok to record it the way that I have.

So put it all in picture form:

  1. Ok, I didn’t include a pic for the initial $60 deposit :slight_smile:

  2. The itemised second invoice:

  3. Supplier Invoices:

  4. Summary of Expenses (Interior Design):

    I personally don’t see the fact there’s a debit of 665 and a credit of 60 as they are explained in the description field and it obviously comes out correct.

I just want to make sure I’m not making some form of an accounting blunder here.

*She initially called it a mobilisation fee but on the final invoice it’s a deposit (neither here nor there).

As long as you put the 60 credit back to the same account as the initial 60 all looks ok.
There is a debit of 665, as that the total of all the debit entries - first 60 +80 + 375 + 150.
Totals of debits and credits are just accumulations and don’t relate to actual transactions.
If you processed a third invoice, the overall totals would grow by the values of that invoice.

Thanks @Brucanna. I thought so, I just wanted to be sure. Thanks again.

The answer confuses me. (This is something that a Journal Report would be very helpful for troubleshooting, @Lubos.)

All you did was to pay a retainer, which should be recorded as a Customer credits asset on your books until you receive an invoice against the prepaid amount. Once you receive the invoice and the full amount becomes an expense on your books, you should partially credit it against the Customer credits asset and partially credit it to Accounts Payable. Finally, you should pay the balance due from Cash.

From what I recall from Accounting 101, it should look like this:

  1. Make advance payment to supplier:

Dr. Supplier credits $60
Cr. Cash $60

  1. Receive invoice from supplier:

Dr. Professional fees $605
Cr. Supplier credits $60
Cr. A/P $545

  1. Pay supplier balance due:

Dr. A/P $545
Cr. Cash $545

Transaction #2 is recorded in Manager as a Purchase Invoice. Transaction #3 is entered through Spend Money.

But how is Transaction #1 recorded in Manager? Spend Money does not give the Supplier credits account as an option. Neither does Debit Notes. Even Journal Entries doesn’t. Do I really have to create a separate asset called Advances to suppliers?

(For that matter, how do I record an advance payment from a customer in Manager? I would think I would want to debit the received payment to Cash and credit it to the Customer credits liability account, but Receive Money does not allow me to credit the payment to Customer credits, despite what the Guide says at http://guides.manager.io/businesses/customers/customer-credits.)

Some help here, @Tut, please?

First of all, reread the original post. @d3mad received an actual sales invoice from the supplier, so a purchase invoice would have been appropriate, as would Receive Money against the Accounts payable account and the supplier’s subaccount. A separate question is whether the supplier was entitled to send that invoice–probably not, since no work had been performed. It should have been a deposit against a quote or contract, but no harm done.

Your confusion about Customer credits and Supplier credits traces to the change announced here:

Those two accounts are no longer accessed directly, but as a result of excesses in Accounts receivable/payable, respectively the absence of specific invoice numbers when transactions are entered.

@Tut, Well…

I’m about to make a much bigger purchase with a much heftier deposit required.

I have a quote from the supplier and am about to commit, ie pay the required deposit.

Reading @Jon’s post, I’m pretty sure I understood it and wanted to confirm the manager way of doing it. Is a Journal Entry the way to do the advanced payment? I just tried to do it, but remembered (whilst trying to do it) that you can’t journal a cash account.

I get steps 2 and 3, but how best to account for the spend and have it appear against the supplier so that the invoice will later be paid by the credit.

My thinking is to make step 1 a spend money from the cash account to accounts payable against the supplier which will appear as a credit for when I process the invoice.

Is that correct?

edit: in placing the advanced payment/deposit, do I attribute a tax to it or leave it without a tax code and leave that to the invoice when it’s issued? I have a recollection that I leave it out as the invoice will allocate the tax accordingly

No, and you are correct.

Unfortunately, @Jon’s post refers to obsolete procedures. Read the release notes I cited earlier if you haven’t yet.

Yes.

Sounds like I’m on the right page (see, I AM learning!)

  1. Spend Money from the cash account against the supplier (applied no tax code)
  2. purchase invoice once issued get’s entered and supplier credit automagically applied (GST code applied to each line item as required)
  3. view the purchase invoice and spend money from the cash account to finalise it (apply no tax code)

I think my greatest confusion is now coming from the tax side of things. But I just ran through the above process in a test account and came up with a result that looks correct in relation to monies paid, and GST liabilities (well, as expected a reduction in GST liabilities since it was paid to a supplier).

Thanks, @Tut. So for Transaction #1 in my prior posting, please confirm that the correct new method of entering it in Manager (assuming it was an advance payment prior to the receipt of an invoice) would appear to be Cash Accounts > Spend money then this, leaving the Invoice (optional) field blank:

That works on the surface, giving the correct post-transaction account balances in my test Business (all balances starting at zero), as shown in the Summary:

However, a look into the beloved General Ledger Transactions report reveals that there’s some messy behind-the-scenes movement of the money into and out of the Accounts payable account, which really shouldn’t happen:

In other words, if we had a Journal report, we would see the following for Transaction #1:

Dr. Supplier credits $60
Cr. Accounts payable $60
Dr Accounts payable $60
Cr. Cash $60

Really messy, especially because the $60 never really belongs in the A/P account at this point, but even messier because the some of the “automatic” transactions in the G/L Transactions report are totally missing their descriptions, and their hyperlinks don’t work. That, plus the absence of a Journal report would make trying to find an error involving this transaction a nightmare.

It appears I am troubleshooting the exact same functionality within the program tonight and had some success.
In my case, the customer prepaid $100 for future services. I received it as Cash under the Cash Accounts tab.
As this was technically Unearned Revenue (a liability) I just made a new account under Liabilities titled Unearned Revenue.

On the Sales Invoice, I added a new line and selected Unearned Revenue as the account and -100 as the unit price.
My tax rates (US Tax Exclusive) were off until I made sure to set the rate specifically for the -$100 line item. Then everything was much closer, but the tax is now overcharging by $0.01.

So while this post is related to invoices and belongs here, I believe it also happens to turn up this issue:

As I am going back and reading this thread now, I am still scratching my head at best practice/expected behavior.

Not messy at all, its just the double entry at work due to the Manager bonus feature of Supplier Credits. The 60 does belong in the AP as its a payment to a Supplier its just that Manager has provided Supplier Credits to handle/separate deposits/overpayments . Most accounting software doesn’t have that feature, so all you see is an AP account with a negative balance - so no mess.

If Manger didn’t do the background transactions then the User would have to post the deposit payment directly to Suppliers Credits, then after the invoice arises transfer the deposit to AP.

Doing the processing manually eliminates the mess but creates additional work. My preference is the automatic (look no hands) background processing.

With regards to finding errors, I would rather put extra focus on getting the input right so the need to chase is eliminated, but if required, reconciling the offending account is more useful then perusing various reports.

Yes, @jon, you understand it all perfectly. Your frustration stems from the fact that Accounts payable/receivable are now used as gateway accounts, passing deposits through to Supplier/customer credits. I concede that appears to involve more transactions as a deposit is magicked to its final resting place. But only one must be input by the user. And this does away with the need for separate advance deposit accounts under assets and liabilities and subsequent journal entries to move deposits to Accounts receivable/payable once the actual invoices come in. So, less manual intervention and more automatic. And all receipts or payments are handled the same way–no need to keep two separate processes in mind based on whether or not you have an invoice in hand.

@semtex, you are making things harder than they need to be, though it appears you understand the concepts. If you read my recent response to @jon and @brucanna’s recent post, combined with release notes for v16.7.73 mentioned above, you should be able to see how simple this has become.

This is a common occurrence with Manager features: they are sometimes a little rough when first introduced, but trend toward more elegant implementation over time.

No, the $60 (actually, negative $60) does not belong in Accounts payable until an invoice is received. With no invoice, there is no impact on A/P because nothing is payable at that point. There is an asset of $60 reflecting the pre-payment. If and when the first $60 of work is done and invoiced, then and only then is the $60 is credited back to the asset account and debited to the expense account. Besides, even the way Manager does it, the -$60 doesn’t stay in A/P; it’s credited back out the moment it’s debited in. That’s the messy part.

If Manager wanted to handle overpayments and prepayments to suppliers as contra-liabilities in the A/P account rather than as assets in the Supplier credits account, that that would be technically correct (albeit not the “right” way of doing it); in that case, though the contra-liability would just remain in A/P and there wouldn’t be a Supplier credits asset account at all. Not the “right” thing, but acceptable. But to debit A/P and then immediately credit A/P and debit Supplier credits is very inelegant (albeit mathematically equivalent). It’s like trying to calculate the sum of 1 and 2 by starting with 1, adding 1,375,279.37, then subtracting 1,375,279.37, and then adding 2. There was never anything payable at that point (i.e., nothing had been invoiced), so A/P should not have been touched, not even momentarily.

Not at all! Since the $60 is moved to Supplier credits, when the invoice comes in there has to be a journal entry (automatic in this case) to credit the funds to back out. And if you follow the principle that all payments against invoices should transit the A/P account, then there will necessarily be a credit to Supplier credits, a debit to A/P, and an immediate credit to A/P, all in the same amount. (It’s not inappropriate to transit A/P at this point, since an invoice has been issued and a payable liability has been incurred, albeit very transiently.)

Indeed, here’s what the General Ledger Transactions report looks like in Manager after a $60 Purchase Invoice is posted and the supplier credit is automatically applied against it:

So even messier now. Manager has for some reason created two new sets of net-zero debit-credit transactions in A/P, and it has created a new description-less entry in the Supplier credits account. So for my Transaction #2 above, this is what it is doing (for a $60 invoice this time, to keep it simple):

Dr. Professional fees $60
Cr. Accounts payable $60
Dr. Accounts payable $60
Cr. Supplier credits $60
Dr. Accounts payable $60
Cr. Accounts payable $60

Again, mathematically correct, but terribly inelegant and obfuscated. Manager is following the general principle I cited above of transiting invoice payments through A/P, but it’s doing it twice for some reason.

Overall, this simple transaction chain of “pay supplier”/“receive invoice”/“apply credit” is creating six entries in the A/P ledger when only two are necessary (or four if you follow the principle of transiting A/P for all payments against invoices). In other words, why isn’t it just doing this:

Dr. Professional fees $60
Cr. Accounts payable $60
Dr. Accounts payable $60
Cr. Supplier credits $60

…or even this:

Dr. Professional fees $60
Cr. Supplier credits $60

?

@jon, I guess all this is a matter of perspective. I look at things through the lens of my original experience with a paper journal, from which transactions were transferred to individual paper account ledgers by hand. That was tedious and error-prone. Software-based accounting came along with the possibility of combining things into a general ledger database, from which variously sorted extractions can occur. But typically, we still look at the products extracted from the general ledger in formats designed to mimic the old paper-based systems. Looked at that way, a general ledger is something akin to a scratch pad. Transactions can move in and out, back and forth, and be manipulated in all sorts of ways that don’t really matter as long as the end result is correct. For a computer, your exaggerated example of how to add 1 + 2 is no harder, and takes only an unnoticeable fraction of a second longer, than the more straightforward approach we would use on paper or in our heads. So what does it matter?

What seems to matter from your perspective is having the simplest, leanest general ledger transactions report that can be designed. I admit that might be a sign of a particular type of software efficiency. But what you’ve overlooked is the steps that might be necessary (and I don’t know what they are) to associate the debits and credits with the right customer and supplier subaccounts, not just the control accounts you list.

And I am more concerned with the routine user interface and experience, how simple the process can be for someone trying to run a business. The fewer transactions I have to enter, the better. I don’t care what hoops the application jumps through behind the scenes, even if it means a more complex transactions report. The fact is, that transactions report is meaningless to me, because it presents information in a way that didn’t previously exist and that I don’t know what to do with now.

I don’t doubt the report could be streamlined if the software was redesigned with that goal. But that wouldn’t be my goal for any accounting application. I don’t care whether transactions pass through Accounts payable/receivable on their way to somewhere else, potentially putting transient values in conflict with questions of whether income or expenses should be recognized yet or not. After all, I can’t even interrupt the process to see such transient results. I click a button and see the desired, correct outcome. And I didn’t have to thumb back and forth through pages of multi-columned green paper or sharpen my pencil.

The basis of every purchase is a Contract, so to be very technically correct the liability (accounts payable - amounts owing to supplier) arises as soon as the purchase contract is agreed. The invoice documents the agreed purchase contract and makes a demand for payment.

In the majority of purchase contracts the arising of the liability and the issuing of the invoice occurs simultaneously - at the sales counter - hence the Invoice is processed in lieu of the contract.

However, when there is a timing difference between the purchase contract and the issuing of the invoice there exists an off Balance Sheet Liability which technically should be brought to account if the financial statements are to reflect the true position of the business however this purchase contract liability tends to get ignored until the Invoice arrives.

If a term of a purchase contract requires an advance payment, then that payment is part settlement of the purchase contract liability - reduces the amount owing to the supplier.

For convenience rather then correctness, accounting generally ignores the contract as a source document/transaction as the Invoice is a viable substitute for most liability recognition purposes, however other purchase contracts are brought to account without invoicing - finance leases.

EDIT: Therefore if the purchase contract liability is appropriately taken up , rather then being deferred, then any advance payments would be settled against that liability and the necessity for Supplier Credits and the resulting “messy” background accounting entries would be eliminated.

1 Like