pro-forma invoices: documentation doesn't match implementation

Dear accounting experts, could you please shed some light upon this issue?

http://de.wikipedia.org/wiki/Proformarechnung (German)
http://en.wikipedia.org/wiki/Pro_forma
describes the various usages of the term "Pro Forma Invoice"

IMHO the content of a pro forma invoice depends largely on the usage and involved parties / countries

I think in most cases pro forma invoices must not produce account moves
- nevertheless, if the shipment of goods triggers VAT calculation AND no commercial invoice is issued in the same period - it might be useful to create the associated move lines.

One client reports that the pro forma invoice are used only for customs and are not posted in the accounting system.

a very complex issue.

In PL we understand PRO-FORMA invoice the same way. No number and no
accounting. Then when customer pay the pro-forma invoice we have to issue
normal invoice in (probably) 7 days.

In our local systems pro-forma invoice is usually printed from Sales order.
So it is not related to invoice functionality at all.

But it can have some functional drawback (not formal) in such case. Even if
we issue pro-forma invoice we expect some functionality for checking if this
invoice is paid or not.

When I red docs I remember that it was: pro-forma - no number but WITH
accounting move. So I didn't test it thinking that it would be wrong for PL.
Now you are writing that it is probably good for PL.
GG.

1. A pro-forma invoice is used to make a "financial offer" to the customer. If the customer agree then the order will be accepted, processed and the proforma invoice get's a real invoice.
2. A pro-forma invoice is used to give your customer a document to prepare import-export documents to calculate the total impact of a sale, before the sale is a fact.
3. Some use it as a pre-payment document before delivery (e.g. webshops) to avoid transactions before payment is received and the salesdeal is a fact. (It is miss-using this functionality as customer has no legal invoice to pay and could not accept it for payments)

In both situations one would not want accounting entries in his OpenERP system. So current build functionality does what is needed for both situations and think this is the right behavior.
It correspondents also to the many links on internet and act equal to e.g. Baan en Sap software regarding no financial transactions.
That means the doc text is wrong.

2010. március 30. 13.30.32 dátummal Jan Verlaan (Veritos) az alábbiakat írta:

> In both situations one would not want accounting entries in his OpenERP
> system. So current build functionality does what is needed for both
> situations and think this is the right behavior. It correspondents also to
> the many links on internet and act equal to e.g. Baan en Sap software
> regarding no financial transactions. That means the doc text is wrong.

It is common case that companies receive pro-forma invoices and the supplier
only ships the goods if the payment is made. Exactly as the prepaid policy
works with sales orders in OpenERP. The customer only gets the real invoice
with the shipment.
How would the manager at the customer's site issue a payment order for a pro-
forma invoice that has no accounting entries?

Regards,
Dukai Gábor

In spain pro-forma invoice have no number no account movements. Account movements are only registered when invoice is valid. That is when invoice number has been generated.

Hallo,

I confirm, there are many uses for proforma invoices. Normally, it's always to give an indication of value of the goods, but there is no mandatory relation with the sales price ! I confirm the miss-using explained by Jan Verlaan (Veritos) #4 as "invoice" or "quotation" for pre-payment in many situation (web sales is an example).

From my point of view & experience, in EEC a pro forma should never post in the accounting and of course if no posting its not possible to have an accounting document number (but well a number range out of the accounting number ranges. For the other countries a did implementation (China, Japan, US, ...) I never met another use.

Kind regards
Alain

On Tuesday 30 March 2010, you wrote:
> In spain pro-forma invoice have no number no account movements. Account
> movements are only registered when invoice is valid. That is when
> invoice number has been generated.
>
Here, too.
AFAIK there is no formal definition for Pro-Forma in Greece. So, we use them as
an internal way to tell our customers what the real invoice will be like
(little more formal than "draft") and then actually issue the invoice. Thus,
we shall not have account movements.

Thanks all for your opinion. To sum it up, is you common the following?
- the use for accounting moves associated with pro-forma is not common enough to be the standard in OpenERP
- the current implementation is ok
- the doc needs correcting
Lionel

On Thursday 01 April 2010, you wrote:
> Thanks all for your opinion. To sum it up, is you common the following?
> - the use for accounting moves associated with pro-forma is not common
> enough to be the standard in OpenERP - the current implementation is ok
> - the doc needs correcting
> Lionel

++

As Ana Juaristi said, on Spain pro-forma invoices do not have number nor accounting moves.

I've seen them being used mostly as a kind of "contract":

   - In the context described by Jan Verlaan.
   - When the partner needs the pro-forma invoice as a justification for asking for a subsidy/subvention.
      (For example, last year subventions where given to companies changing their software; the bought/implantation of an ERP takes some time, and usually it is not invoiced/accounted until it's done; so those companies needed a pro-forma invoice to opt for the subvention if the bought/implantation of the new software was still not performed/completed).

So, +1 to Numérigraphe words

OK, I changed the wording to say that Pro Forma invoices don't have an invoice number or accounting entries, but I'm not an accounting expert, so please review the changes here:

http://bazaar.launchpad.net/~openerp-community/openobject-doc/trunk/revision/475