← Back to team overview

openerp-expert-accounting team mailing list archive

Re: About Prepayment in ecommerce workflow

 

Hi guys

Interesting thread .... And it shows the complexities of all the different
conditions/rules we are challenged with addressing for our clients. I just
wanted to contribute another point. The treatment we get faced with here in
the US also differs when the accounting method used by the the client. Here
there are Cash methods or Accrual method of accounting.

So the treatment if running a under a cash method on the accounting side
would put prepayments/deposits immediately into the cash earned bucket and
it is recognized as income. (In this instance you also have to keep a
shadow account tracking the prepaid balance). But from an internal revenue
perspective you already earned it.

Then if the client is using an accrual method a prepayment would fall into
a prepaid account. And as Eric mentioned would be considered a liability of
the business for accounting reporting (unearned deposits or prepaids all
fall into this) until earned.

I recognize VAT capture and ultimate payment also complicate things for
most people in this thread as well. My point is even within a single
country the system really needs to be flexible.

It is always interesting discussions nonetheless.

Dave Mitchell
Mitchell.dm@xxxxxxxxx
Novapointgroup Group



On Thursday, November 21, 2013, Gustavo Adrian Marino wrote:

> Here in Argentina we use for prepayment invoices a special product, with
> an income account that represent the liability
>
> I am not an accounting, I will try my best
>
> When you confirm the prepayment invoice, you will have a movement between
> Debtors, received VAT, and the Payment in Advance (a Liability).
> After payment of the prepayment invocie, you will end with a debit in cash
> or bank and a credit on Payment in Advance, reflecting the fact you have
> got money and a debt
>
> When the actual goods are delivered, revert the liability (with a refund
> of the prepayment), and thus you have a debit on received VAT, a debit on
> Payment in advance (cancelling the debt), and a credit on customer account
> (exactly the same situation as a normal payment from the customer).
>
> Then you can proceed to cancel the real final invoice, using the customer
> credit plus any additional customer payment
>
> Of course, you have always the posiibility to get a payment WITHOUT
> invoice from the customer in advance, that will generate a credit on his
> account that can be used at the end to pay the final bill. But, from the
> legal point of view, it is not the right way of doing things, allthough is
> a common practice
>
> Regards
>
>
> 2013/11/21 Ferdinand <office@xxxxxxxxxx <javascript:_e({}, 'cvml',
> 'office@xxxxxxxxxx');>>
>
>>  On 2013-11-21 07:10, Nhomar Hernández wrote:
>>
>> IMHO all this must be "hidden" from end users.
>>
>> a possible way is to link a "debtor liabilities" account to every
>> receivable account and a creditor receivables to each liabilities account.
>>
>> rules:
>>
>>    - if the balance of a receivable account of a partner becomes a
>>    liability the amount is automatically transferred to the liabilities
>>    account and back if the condition does not exist any more.
>>     - for reconciliation the moves of both general accounts must be
>>    listed and in case of reconciliation the necessary move lines must be
>>    created in the background.
>>
>> this simple solution worked for us already many years in our previous
>> accounting system.
>>
>> this solution complies with the general rule that receivables and
>> liabilities of different partners must not be balanced (as it is now)
>>
>> hope that helps
>> regards
>> ferdinand
>>
>>
>> 2013/11/21 Ferdinand <office@xxxxxxxxxx <javascript:_e({}, 'cvml',
>> 'office@xxxxxxxxxx');>>
>>
>>> In the USA, money you receive from a customer prior to goods or services
>>> being provided is a LIABILITY, not revenue, so it cannot be credited to AR.
>>
>>
>> I am sorry if I make a confusion.
>>
>>  When I said "Prepaid - Income" It is:
>>
>>
>>  http://accounting-simplified.com/prepaid-income.html
>>
>>  Sorry for the confusion.
>>
>>  Regards.
>>
>>  BTW in OpenERP we are managing with "receivable" account, but it is
>> seen ugly by some accountants.
>>
>>
>>
>>
>>  --
>> --------------------
>> Saludos Cordiales
>>
>> Nhomar G. Hernandez M.
>> +58-414-4110269
>> Skype: nhomar00
>> Web-Blog: http://geronimo.com.ve
>> Servicios IT: http://vauxoo.com
>> Linux-Counter: 467724
>> Correos:
>> nhomar@xxxxxxxxxxxxxx <javascript:_e({}, 'cvml',
>> 'nhomar@xxxxxxxxxxxxxx');>
>> nhomar@xxxxxxxxxx <javascript:_e({}, 'cvml', 'nhomar@xxxxxxxxxx');>
>> twitter @nhomar
>>
>>
>>
>> --
>> Ferdinand
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-expert-accounting
>> Post to     : openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx<javascript:_e({}, 'cvml',
>> 'openerp-expert-accounting@xxxxxxxxxxxxxxxxxxx');>
>> Unsubscribe : https://launchpad.net/~openerp-expert-accounting
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
>
> Gustavo Adrian Marino
>
> Mobile: +54 911 5498 2515
>
> Email: gamarino@xxxxxxxxx <javascript:_e({}, 'cvml',
> 'gamarino@xxxxxxxxx');>
>
> Skype: gustavo.adrian.marino
>
>
>
>
>

References