Invoice delegation

From Expense reimbursement discussion:


Sometimes you need to delegate the purchase of goods, but the invoice need to be in the company name.
It can also be useful if the customer delegate someone (the customer accountant for example), to keep track who need to pay the invoice on behalf of the customer.
For this reason it wold be useful to have a “delegated to party” field in the invoice.

Theory of operation

supplier invoice

When you post the invoice it will also create a payable move on behalf of the delegated party (if the field is not empty), and it will considered the invoice paid.

customer invoice

When you post the invoice it will generate also a receivable move for the delegated party.
In this case the invoice will not be automatically paid until the receivable move is not reconciled

Do we really have to take care about the customer invoices?

For me it is not rellevant that the customer invoice is paid by a third party as you will have the invoice paid and you do not have to do anything else.

In the supplier case it’s important to know that the invoice is paid (so you will not pay it twice) and also know that the amount is owed to another party.

Yes, if your are doing direct debit you must take from the right party.

I do not think it should be considered as paid until the delegate is paid.

Ok, I need this feature, so I’ll try to implement it.
One technical question:
Should I create a payable move based on the “delegated party” payable/receivable (instead of the party in the invoice)or should i create another move “linked”? (reconciled with the one generated from the invoice and the reconcile status delegate_to this new move)(In this case this should be an action/wizard IMHO)

The first case is the simplest to implement, but after you post the invoice, this should/cannot be changed easily, the user need to create a move manually if the delegate changes.
The second case is more flexible (sometimes you send group of people and don’t know who will pay for the invoice), and the delegation can be changed via the wizard.

I’m more in favor of the first case, but I want your opinion on this.

I think it should be done on two steps for reporting purpose. The original party is the one who is buying/selling. So if we do report based on cash flow, it is important to have a trace on the original party accounts.
Also I think this operation should be manageable on the invoice with a field to fill but also directly on a payable or receivable line. It should be quite similar to the grouping method.

so it’s more or less second option(but not in a wizard form)?
Let the invoice module create the receivable/payable move(in favor of the “invoice party”,
but if the “delegate party” field is populated, create another linked payable/receivable move(reconciled, and the reconcile status delegated to this new move) in favor of the “delegated party”.

Yes but I think a wizard is also needed. Indeed the wizard and the invoice should call the same method.

I have an use case which seems suitable for this feature but I’m not sure if will be completly supported:

When working with as an accoutant sometimes you pay in advance some amouts for your customers and include this amount on the services invoice. But the invoice of the advanced amount is always in the name of your customers (as the customer is responsible of paying it). This is called suplido in Spanish, don’t know how they name on other languages.

So from the accountant point of view they will create one invoice with two lines:

  • One for the service (with VAT)
  • Other with the advanced amount (without VAT)

And then from the customer point of view it will receive two invoices:

  • One from the accountant including both lines and which will be the one that will be paid
  • Another from the real supplier which the total amount is inclued on the accountant invoice (which is delegated to the accountant)

The issue here is with the first invoice of the customer, which includes a line which is not a expense and as we only allow expenses on supplier invoices it’s not possible to add use the correct account for this invoice.

Here are some examples of the required moves for this specific case.

I do not understand how can there be two invoices for the same service managed by two different entities. Only one entity must have received the invoice and I guess it is the accountant otherwise it would not know the amount to advance.

I do not think it is very wise from the accountant to mix its own services and the advance payments he does in the same invoice because it is confusing for his customers.

Indeed I think this looks more like a “employee”'s expense than a supplier/customer flow. So for me, the accountant must create a document/letter to request reimbursement to attach with the original invoice.

For now i implemented the “naive solution” (more as a proof of concept):

  • create a move based on to lines_to_pay
  • create an “opposite line” and reconcile it to the old payable/receivable line
  • delegate the reconciliation to the new payable/receivable line with another party
  • write the party to the “delegated_party” field

seams to work nice for my user case, but there are some side effect i want to discuss first:

  • Should the “opposite line” be more like a cancel move (credit/debit negative), or just a move with the credit/debit swapped.
  • the pay wizard will try to create a move for the original party, should the wizard take into account the delegated party?
  • the amount to pay will show zero, should be display the amount the delegated party should pay?(as a separated field perhaps)
  • payment line (i didn’t check it) will probably be affected as well, should i fix it, or just list the payment line the original party has payed?
  • for now the “original party” can pay some line of the invoice, and then delegate the rest (this is because I use the lines_to_pay field), is this behavior a feature or a bug?
  • How should i deal with partially payed line (if this is possible, didn’t check it)?
  • you can chain delegate in theory (you can change the delegated party and create a chain of moves, the one that will need to pay the invoice is the last person on the chain), should i leave it as a feature?
  • should i create a cancel delegation option? or this will be something the feature above can provide? (going full circle by delegating to the “original party”)

What is the purpose of this field?

I think negative value will be better because it will not increase artificially the total of debit and credit.

Other questions can not be answered without viewing the code.

the code is not complete, this is some side effect i witnessed/think could append and what should the module/path should do.
the first “functional” code is here:
it’s dirty… it not complete… just an experiment.

So you are talking about the amount to pay on the invoice.
I think the lines_to_pay should provide the delegated lines instead of the original.

The party constraint on payment lines should be updated to use the delegate party.

For me, this can not happen because:

  • delegation should be done on the invoice before posting
  • or if done manually it is at the move line level which will remove the possibility to add payment lines on the invoice.

Delegation on the invoice should be done prior to posting. So there is no partial case.


I do not think. The accountant will cancel/delete the move or make a new delegation.

It’s only one invoice, but the accountant uses the invoice line to request the amount paid in your name. After request the payment he sends you the final invoice which which it paid in advance. Normally you receive first the accountant invoice (with the full amount) and then the invoice of the other supplier which has been already been paid by the accountant.

For me, it is wrong because he did not sale any services with this line. It is an abuse of the invoice. It must send a request for payment for example.

I do not see why it is sent in two step. The accountant need to have the supplier invoice to make the payment so he can send the request and the original invoice at once.

I think now i can draft a “formal” Feature post with all the element in this discussion. But before that:
Should this a separate module, or just a new feature of account_invoice module?

This modification is a trivial one (and doesn’t disrupt the “invoice” workflow), so i think it can be incorporated in the account_invoice module. But i want ask for opinion on this.

In each case, the work will be trivial (for me), so don’t factor this in the decision.

I think it is better to have it in existing modules because it is a feature that may be used by other modules that create invoices.