I am dealing with the same issues alluded to in threads such as this and this. Our base currency is ZWL, but we are allowed to transact in USD as long as all related taxes are paid in the currency of the transaction.
I have created new accounts for employees in USD and paid last month’s salaries in USD. This means the payslip deductions and contributions are payable to the authorities in USD. However, between the date of the payslips being generated and the payment of these deductions and contributions there has been fluctuation in the exchange rate, and so the balance sheet accounts (which are denominated in the base currency of ZWL) no longer balance. See one example here:
How can I account for this difference? When making the payments there is no option to specify the amounts in ZWL, so Manager cannot automatically allocate it to Foreign exchange gains (losses). I do have a custom foreign exchange gains / losses account that I created for a very similar reason a while ago, so I could use a journal entry to clear it through that. But that involves extra steps and, as @lubos himself said:
Perhaps we need a way to set the currency of the deduction / contribution accounts? Or they should automatically assume the currency or the employee they are used for? Or maybe just being able to specify the payment amounts in the base currency would be adequate.
It is not clear what you mean. Did you denominate your employees in USD? Or did you create new accounts for something in the chart of accounts? Please clarify.
What is this account for? Why do you think it should “balance?” And what do you mean by “balance” in this context? If you are debiting and crediting in a foreign currency, those will be converted at the exchange rate in effect on the date of the transaction. Unless I am misunderstanding what you mean, there is no reason to expect any sort of balance in an account recording deductions or contributions (if that is what this is).
That already exists. Deductions and contributions are automatically denominated in the currency of the employee. If you change employees, the currency of the transaction changes to match.
Sorry I wasn’t clear. Yes, I created new employees denominated in USD.
This particular account is for ZIMDEF, which is an employer contribution based on the gross salary. But there are others too, such as a social security deduction and contribution, workers’ insurance, and PAYE.
Sorry my terminology wasn’t clear (or even completely wrong). Once I generate the payslips, the deductions and contributions owed to the authorities appear under Liabilities in the Balance Sheet on the Summary page. If these deductions and contributions come from payslips for employees denominated in the base currency (ZWL), then once I make the payments the amounts showing under Liabilities are reduced to zero, until the next payslip is generated. This means I can easily see what the business owes to the authorities, just like with accounts payable.
However, if the deductions and contributions are payable in another currency (USD in my case), any changes in the exchange rate between the issuing of the payslip and the payment of the deductions and contributions means that the amounts showing under Liabilities will not be reduced to zero, even if I have paid exactly what was owed in USD. This makes it look like the business has outstanding amounts owed to the authorities, although this might not be the case. As months and years go by these differences will accumulate to the extent that what’s shown under Liabilities bears no resemblance to the actual state of our accounts with the authorities.
OK. If I look at the Payslips tab I can see the deductions and contributions are expressed in the currency of the employee, so you are correct there. I guess what I meant was that I would like it if these accounts were treated similarly to customer accounts designated in a single currency. In that case I can receive a ZWL payment from a USD customer, but in doing so I have the option to specify the USD equivalent amount so that I can clear an outstanding sales invoice if I am satisfied that the payment is of equivalent value. Manager would calculate the implied exchange rate based on the figures I enter, compare it to the exchange rate entered in the settings, and assign any difference to Foreign exchange gains (losses).
In my case now with the payslips, if the deductions and contributions for one month come to US$10.19 (as in the example screen shot above), I would like it if my payment of US$10.19 to the authorities brought the balance of the account under liabilities back to zero, just like a payment of US$10.19 from a customer against an invoice for US$10.19 would reduce the accounts receivable for that customer back to zero (assuming no prior history).
I guess part of the problem is that to our authorities, no exchange rate will make them happy that a ZWL amount is equivalent to a USD amount. If we incur a tax in USD, it has to be settled in USD, not in ZWL, regardless of the exchange rate. I imagine this is not a common scenario elsewhere in the world.
The question is how much you must remit in USD when the deduction/contribution was in USD. Do you have to remit the same USD amount as was deducted/contributed? Or do you remit in USD at today’s exchange rate an amount equivalent to the ZWL equivalent amount on the date of the original transaction? Does my question make sense?
I think that to get good answers on how to handle this in Manager, you need to talk with your accountant and get an exact description of how tax liabilities are to be settled. Generate a worked example. Then forum members can help you figure out how to make the right entries.
Yes, I think I understand you. It’s a fair question. However, in this case I think I understand my accountant pretty clearly, and that the amount to be remitted in USD is the amount as calculated and shown on the payslip, regardless of whether it is remitted on the same day or a week later. The ZWL amount to be reported for the general accounts must be at the exchange rate on the date of the transaction, so the day the payslip is generated. This happens correctly.
I have downloaded the relevant tax tables from our tax authority, updated and generated the payslips, and sent them to my accountant for verification and filing to the authorities, which has been done.
Let me try to construct a simplified example. I will use just the PAYE, but the process is exactly the same for the ZIMDEF and NSSA deductions and contributions.
Employee A earns a gross monthly salary of US$1,000. The tax tables tell me the PAYE owed is US$221. I enter this information and generate the payslip on the 25th of August, and under the Liabilities section of the Balance Sheet I see an amount of ZWL$19,890 for the PAYE account (US$221 × exchange rate of 90).
The PAYE is payable before the 10th of the following month, so on the 5th of September I go to the bank and make a deposit of US$221 into the tax authority’s account. I record this transaction in Manager. However, between the time I generated the payslip and the submissions were filed with the authority by my accountant on the 25th of August and the time I made the payment on the 5th of September, the exchange rate has changed, and Manager now shows my payment as being equivalent to ZWL$22,100 and a resulting balance of -ZWL$2,210 showing under Liabilities for the PAYE account.
My tax authority is happy that I have settled the account, I am as happy as anyone can be paying taxes, but Manager tells me I have overpaid.
Your explanation is simpler than I feared it might be. At least it is easy to know how much to pay to settle your account with the authority. I understand why the government does this in a hyperinflationary environment: it wants stable-currency assets, and when you settle the liability at US$221, they are getting more in terms of ZWL equivalency. In other words, they are punishing you for conducting part of your business in foreign currency as you try to shield yourself from the effects of inflation.
You can force equivalence when paying your employees from bank or cash accounts in any currency. That will take care of their balances in Employee clearing account. But you cannot force equivalencies when making a payment posted to your tax liability account. You are stuck making a payment from a USD-denominated account, and I don’t see any way to automatically get exchange movements into a Forex gain/loss account.
I agree it’s inconvenient to have differences build up. So I think you are going to have to resort to shuffling amounts around with journal entries. Again, I’d ask your accountant for advice about this. Obviously, every other local client will be confronting the same issue.
Yes, thankfully this part is easy, but I can’t get it from the Manager Summary screen. I have to manually add the amounts from the payslips, or just wait for the figures my accountant sends me after she has cross-checked my payslips.
Yes, I think you’re exactly right.
Yes, I think for now I’ll allocate the difference to my custom foreign exchange gains / losses account that I referenced in my first post. I’ll be sending my figures to my accountant soon and will bring it up with her then as she’ll see that account anyway.
Hi Graham
If you pay a USD liability from a USD account it will balance. If you pay a USD liability from a ZWL account account you can still back it up with an inter account transfer (cash account) from a USD account to a ZWL account. When you do these transfers you can dial in any rate that may suit.
I pay my wages in ZWL officially, but do not have the ZWL to do it. So I usually do such a transfer.
Unfortunately this is not always true, and is the essence of the problem. Manager represents all liability accounts in the base currency on the Summary screen. If exchange rates remain constant between the incursion of the liability and the paying of it, then there is no problem.
As you can see from the screen shot in my opening post, I incurred liabilities of US$6.95 + US$3.24 = US$10.19. I then paid US$10.19 towards this from a USD account. This left a balance of ZWL$2.23 owing, because changes in the exchange rate meant that the liability and the payment were of different values when converted to the base currency on their respective days.
I know this is not correct, but I have opened a bank account called “overs and unders” to make all these things disappear. This way I can produce a schedule of exactly what happened. You can also be careful about the date at which the side of the transaction you can control is stated. Paying quickly helps too.
When my accountant submits my P/L to ZIMRA he also cancels out the manager.io exchange gain as it is unrealised.
Yes, if I had planned better I could have made sure I did the payment on the same day as the payslip was issued, and I wouldn’t have had a problem.
There are certainly ways of tidying things up, whether through your “overs and unders” account or something like my custom Foreign exchange gains / losses P&L account that I’ll assign the difference to in this case. (I believe when my accountant submits my figures to ZIMRA she will also omit the foreign exchange gains and losses as you have described.)
However, as strange and dysfunctional as our financial system is in this country, I still believe that these issues expose ways in which Manager could be fixed or improved for the benefit of all users. I don’t think we should be resorting to these hacks to get it to work for us. It’s not a criticism of Manager or its developer – it’s likely this is the first time some of these issues are being experienced by users. But if we as real-world users are having these problems, there will likely be others as well, and building Manager to handle these situations will only make it more robust and effective in the long-term, I believe.
To me the obvious solution here would be to allow users to specify the base currency equivalent amount when making foreign currency payments to a liability account. But perhaps there are implications beyond my knowledge of the program and accounting principles in general that would mean this isn’t an option.
I can see your problem, what you need here is for your labor tax liability account (a balance sheet account) to be denominated in USD, which is not possible at the moment.
However, for now, if you don’t want to deal with FX differences, once you issue your payslips, you can immediately transfer the entire labor tax liability to a supplier account denominated in USD, this way manager would take care of all the FX differences for you.
If I understand you correctly, what you would like to see is the appear at end of the Contributions - USD entry line, similar to the other accounts above it:
If yes, then the Chart of Account > Contributions - USD account could have a field which when “activated” would only cause the to appear on the Receipts and Payment forms so that the correct currency match up can occur and the resulting forex allocated with the Balance Sheet account zeroed.
@Brucanna Your illustration is pretty close, but there’s an important difference: When I make the payment, since I’m paying a USD obligation I am paying from a USD-denominated account, so the currency of the transaction is USD, not ZWL as in your example.
I guess having the option to enter the ZWL equivalent could be useful, but that would require me to look up the ZWL amount that Manager calculated for the original obligation and enter that.
If I am paying a USD-denominated supplier, I don’t ever have to enter a ZWL equivalent amount. If I receive an invoice from them for US$10 and I pay US$10 on the same day, a week later, or even a month later, my accounts payable to them is reduced to zero, regardless of how the USD:ZWL exchange rate may have changed in that time.
I was assuming that the same process as your $10 example would apply, the USD denominated Contributions - USD account is just an alternative to a USD denominated supplier or as suggested above “you can immediately transfer the . . .liability to a supplier account denominated in USD” - where the supplier is being a de facto Contributions - USD account.
The balance sheet account remains in the base currency just as the supplier under accounts payable remains in base currency on the balance sheet - albeit the account not being a sub-account of a control account. Understanding there could processing complications / limitations.
Alternatively, payslip deductions / contributions liabilities could be allocated to “suppliers” instead of chart of accounts and then have those suppliers (currency based) grouped under a Payroll Liabilities control account instead of under Accounts Payable.
I’ve just done an experiment in a test business and discovered that I have exactly the same problem with my VAT liability account. Any VAT incurred from USD sales must be paid in USD. (I discussed this in a different context in this topic.)
For reporting purposes I created a new tax code for the USD transactions, but this doesn’t get around the issue of changing ZWL values because of fluctuating exchange rates. I hadn’t picked up on it earlier because by the time we submit the VAT returns for the previous period we have already had many transactions in the new month, and so the VAT liability account is never zeroed out. But you can clearly see the issue here:
The sales invoice generated a liability of US$14.50 which was converted by Manager to ZWL$16.11. When I paid the US$14.50 a couple of days later, Manager converted this to ZWL$18.13 which reflects as an overpayment of ZWL$2.02 in the VAT liability account.
appear at end of the Contributions - USD entry line, similar to the other accounts above it:
field which when “activated” would only cause the 
