Invoicing issue: analysis of the situation with a lawyer

International
1

We had yesterday a great lawyer, who is btw one of the lawyer working with “La Quadrature du Net” a French NGO working on Web Neutrality.

We addressed 3 points:

  • process from order to invoice/payment/delivery (in context of inception for this need)
  • terms of sales of an OFN platform vs a hub selling through the platform
  • GDPR and privacy policy

Here I’ll just tell about the first one, will open separate posts on the other points. Some details will be confirmed on Monday 6th, he is investigating on some points, but here is already the first important points to understand, that are very annoying…

1- The legal requirements around invoicing in France (and seems at least UK and Germany)

Summary law texthere.

Sequential numbering of invoices

In France, the law says that a given enterprise (ID number of an economic agent, so it can be a producer selling directly, or a distributor) when issuing invoices has to issue invoices with a continuous sequence of number: 201, 202, 203, 204, 205, etc. If one is missing, it can be a proof of fiscal fraud, so authorities impose that sequencing to make sure no invoice has “disappeared”.
This seems to be the case also at least in UK and Germany @NickWeir @Oliver @Kirsten https://github.com/woocommerce/woocommerce/issues/2234
@sauloperez @luisramos0 @tschumilas @Kirsten any idea for your countries?

In France is is possible to use difference series of sequences if the activity requires it, like “multiple invoicing systems”.

So if a producer sells through a hub using OFN, and a Food Assembly, let’s say the seller give OFN code A, Food Assembly code B, sales one is done in OFN, invoice 1 would be A1, then sales 2 on Food Assembly, invoice 2 would be B1, sales 3 on OFN, invoice 3 would be A2, etc.

In case of modification or cancellation, you can:

  • either establish a new invoice that replace the previous one, and that has to make a reference to the invoice it replace
  • either issue a credit note / void (negative invoice), that needs also to make a reference to the original invoice it applies to.

2- The very annoying consequence on OFN

Today our invoices are just a “PDF view” of the order, and invoice number is order number. So for a given legal seller, there is no sequencing of invoices…
Also today it is not possible to issue neither a replacement invoice (with separate number and mentioning original invoice number) not a credit note / void invoice (negative invoice, also mentioning original invoice number).

If any of our users get a tax control, they are breaking the law and will get a fine of 15€ per missing or inaccurate information (like a problem in the invoice number), with a limit of 25% of the invoice amount. In France we know that at least one hub uses actively the invoicing system… this is the hub that also print receipts so use OFN as POS system…

This is the seller responsibility, but by providing them an invoicing system that make them illegal, they can sue us back if they get a fine, we have a shared responsibility here.

3- The potential solutions

We need to let our users know and ASAP organize either a fix (we’ll discuss with devs in Porto as it is part of delivery note inception), or a transition toward using an external invoicing system through fluid integration.

A- If we keep an invoicing system within OFN:

  • we need it to attribute a dedicated serie per hub (a legal entity can handle multiple hubs through the OFN), and for each serie, the invoices need to follow each other, in a continous sequence.
  • we need to enable, if a modification or cancellation of order happens after invoice is issued, to issue either a rectification invoice, or either a credit note / void issue, with reference of the original invoice it replace/amend.

B- If delete the invoicing module from OFN:

  • we need to make it easy for a hub to integrate with any invoicing system they use
  • for POS users we need to make it easy for a hub to integrate with an easy to use and value aligned POS

We are planning a call in France with that user and will interview our hubs to see who else is affected… but we can’t make them take the risk to get fined for each invoice they issue. So we want to be transparent and discuss with them solutions.

2

There are two tracks and we should probably explore both

1 - implement simple solution in OFN to be compliant

Because we could build some simple feature that enables each Hub to have it’s “invoices sequence number” that is used for every invoice. This would require some flexibility to change previous invoices (mark an invoice from the past so it’s number gets reused?).

2 - see what accounting solutions we could integrate with

Because the accounting game is a long game (there’s so much to it, isn’t it?).

3

@MyriamBoure the law in the UK is much less strict, although it is of course good practice not to delete an invoice and to use credit notes etc - certainly once you’ve sent an invoice.

I think OFN should stay clear of trying to be an accounting software provider. Integration with existing packages makes sense but will no doubt have to be done at instance level. There is no accounting software that is available in all countries, meeting the fiscal requirements of them all.

4

I agree with @Oliver - I don’t think OFN should try to become accounting software. Consider that we are already on a path to be a ‘global instance’ - so this means we would need to be considering country specific accounting laws constantly. it makes more sense that we think about integrations with existing accounting systems - that are already well-resourced to stay on top of constantly changing accouning best practices.
In Canada - there is no legal requiremet to sequentially number invoices. But, each invoice must have a number, and the number must be unique. And changes to an invoice must reference the previous invoice. But the numbering doesn’t have to follow. For us, WHAT is on the invoice is more precise - and these differ based on province, and in addition there are ‘small business’ vs ‘large business’ requirements in differnet provinces. So if in one OFN instance we can have at least 10 different requirements for legally compliant invoices, it says to me, OFN should not go down this path. Lets be great at other things - and help our users link to or integrate with accounting sofware easily.

Maybe we have unofficial invoices in OFN - but then advise our users of this, and help them identify software that will do the official invoicing for them.