Invoice customer in two currencies for single item

I would like to invoice a customer for a single item with the cost split between two currencies. I believe I can do this in the following way:

  1. Create two customers in Manager, one for each of the two currencies.
  2. Create a sales invoice in one currency as per normal with the item listed with a quantity of 1.
  3. Create a sales invoice in the other currency, selecting the same item but leaving the quantity field blank and entering the balance of the amount due in the second currency.

Is this the best method? A simple trial in a test business seems to show everything working correctly.

Why do I want to do this? We are allowed to make sales in USD and ZWL, but must accurately report income from each currency to the tax authority. Most of the time this is fine, as I have USD and ZWL customers in Manager for each of my customers, so I just use the appropriate one depending on which currency they would like to use for payment. However, increasingly I am finding that customers would like to pay in USD (which is cash 99% of the time, as we don’t have very functional USD bank accounts here) but don’t have the correct change, and I don’t always have the right change for them either. For some of my regular customers I just allocate the difference as credit on their account, but for one-off customers I usually give them the option to pay a convenient amount in USD and the balance in ZWL. I realise that I can accept payment in one currency for a customer denominated in another, but for the purposes of accurately reporting income by currency to our tax authorities it seems I need to issue two invoices.

That’s too much for me to follow. Why not update the exchange rates so that the invoice is translated to ZWL exactly?

OK, let me try to illustrate it with an example:

A customer wants to buy an item that I sell for US$58. Let us say the ZWL:USD exchange rate is 100:1. So, they could pay me US$58 or ZWL$5,800. In either case I could simply choose the appropriate customer account that I have created for them in Manager and issue the invoice to them in the currency they choose to use. Easy.

But the customer might want to pay in USD, but not have the correct change (a frequent occurrence here). I can give them the option to pay US$50 and the balance as ZWL, so ZWL$800 in this case. Although Manager has the option for me to accept ZWL payments against a USD invoice, my tax authority wants to see my income broken down by currency, so I need to issue one invoice for the US$50 and another invoice for the ZWL$800. But both invoices apply to the same single item that I sold.

@GrahamvdR, what you describe sounds correct, but I have not simulated the process in a test company. You have correctly recognized the need to avoid entering inventory quantities twice. This is just the reverse of adding freight-in charges to an inventory item’s average cost.

1 Like

Ok, I understand now. What you suggest should yield the correct result for tax purposes.

However what I am not sure of is this:

Is it really possible to affect 0 quantity. This needs more testing.

What I would do, is:

  1. record a USD invoice ref.X with qty 1 USD100 and add another line without an inventory item (let’s call it receipts in ZWL) for -50.

  2. Record another invoice for ZWL 800 referencing invoice X.

This way you have split the invoicing by currency without adding complexity to the movement of inventory (as it is mentioned only once at it’s normal price). I could be wrong, your method might be better, but it never hurts to have alternatives.

Or succeed in get a report transformation written which pulls out reports by currency to meet your government’s reporting requirements.

Report transformations could potentially help, but not in the way I’ve been working on them so far. The income I’m reporting includes sales invoices, not actual receipts. So if I invoice a customer US$58, that gets included in the income report. If he pays US$50 and ZWL$800 against that invoice, it won’t show in my reports to the authorities, which is why I need to manage the currencies at the invoice level and not the receipt level.

I could potentially create a report transformation to report on actual receipts instead of sales invoices, which would capture the currencies accurately. But my understanding of our reporting requirements is that if I issue an invoice it has to be declared as income, whether the payment comes three months later, a year later, or not at all. The receipt itself is meaningless. If a customer makes an advance deposit for goods, I don’t report that as income. It’s the sales invoice that is reported. Similarly any payments I make cannot be declared as expenses themselves – it’s the purchase invoices I need for reporting.

My approach outlined in the opening post seems to roughly match the guidance I received from my accountant, though she is not a Manager user so was not able to outline the specific steps I should take to achieve this.

Having said all this, it’s possible different people are interpreting the regulations here differently, and another accountant might give me different advice. I’ve received invoices in ZWL for goods I’ve paid for in USD, so either other businesses are flouting the rules to avoid declaring their USD income (highly likely), or we have different interpretations of the rules.

Thanks for the clarification.
I was going to delete my post as on reflection I guessed you were well aware of what could and could not be achieved.

You are correct that in accrual based accounting it is the invoices not payment or receipts that matter.

Thinking about what you are doing, you are actually providing two services

  • Selling items in a specific currency
  • Providing a currency exchange service

As such an approach similar to described above by @Ealfardan would capture it better in my opinion

  • Payment for the full amount in the specified currency (USD58)
  • Currency exchange transaction to provide the change (+ZWL800 -USD8)

The way to do that per invoice is shown in this post for custom reports

I believe the same variables are exposed in report transformations, so it may be possible to combine information from both sources.