Why can't I post bank transactions as T57 (Overseas reverse charge)?

We have a lot of recurring payments that are made automatically through our bank account, which are Overseas reverse charge transactions.  We always check that we have the appropriate documentation for these (invoices with VAT numbers). 

However Sage will not allow us to post bank payments with a T57 tax code.  

When I spoke to someone at Sage on Chat, I was told that these transactions should only be posted as purchase ledger transactions because you need an invoice as per HMRC instructions.

We do have an invoice, but I don't want to post all of our automatic bank payments as purchase ledger invoices and then purchase ledger payments because this will more than DOUBLE our workload!  We currently import our bank transactions into Sage, so I don't want to create purchase invoices and then purchase payments for these transactions.

This is causing me a big problem and Sage don't seem to be interested in helping me to solve it - the operator suggested that I post in Sage City to ask for this to be added to the roadmap for development.

Is anyone else having this problem and have you found a practical way around it?

Parents
  • 0

    Hi Caroline,

    Thanks for using Sage City.

    The program is developed so that it's compliant with legislation. This block was put in intentionally as advised by our compliance team.

    If you're using File Import you import your Supplier Invoices as PI's and your Bank Payments as Supplier Payment on Accounts PA's. You would then just need to allocate the payment to the invoice using Supplier Payment or Batch Supplier Payment if you use Sage 50 Accounts Professional.

    Alternatively, if you like using recurring payments, import your PI's and use recurring entries to post Supplier Payment on Accounts instead of bank payments. Then again use Supplier Payments to do the allocations.

    Or If you want to post it as an idea you can do so here >> Sage 50 Accounts and Sage 50cloud Accounts Ideas

    If this has answered your question please click More > Verify Answer.

    Regards,

    Ian

  • 0 in reply to Ian C

    I'm sorry - but I have called HMRC and we are complying with the legislation - we have all of the backup information required by HMRC.  

    This is a Sage issue, not a legislative issue.

    As I said before, you are asking us to go from importing one transaction to making three transactions and therefore TRIPLING OUR WORKLOAD.

    I'm very disappointed with Sage on this - I have already posted the idea.

    Sage do not care that they are causing us a massive problem in the run up to year end and keep blaming this on legislation, which is simply not the case.  This is a software problem.

  • 0 in reply to Caroline Reid

    Hi,

    If you import a PI and PA it will create two transactions via a single import. 

    You could even look to use something like Bank Feeds to get the transaction to be imported for you to help reduce the workload.

    With all legislation changes, we get them reviewed and signed off by HMRC and our own internal compliance team. If an invoice has been produced it should be digitally recorded.

    I'm unsure if you're from the UK or Ireland but with a lot of the new codes postponed accounting is involved and a PC is automatically posted from the PI, this can't happen with a bank payment.

    The new codes work in many ways the same as the old EC tax codes but the difference here is we enforce them rather than warn you not to use them.

    With everything, this may change in the future based on feedback.

    Sorry, you're unhappy with it.

    Ian

  • 0 in reply to Ian C

    Hello Ian,

    I understand what you are saying but I'm sure you can see that this change has caused us a lot of extra work even if you import a PI and a PA.  We will still have to create two lines in our import sheet instead of one and then we will have to allocate all of the payments on account manually.  

    Our CEO is not happy with the security surrounding bank feels and will not authorise their use - as I work for a software company, it is unlikely that I will be able to persuade him to change his mind.

    We used to use the old EC tax codes when importing our bank payments  This change is very bad timing for us as we are now very close to our financial year end with a MASSIVELY INCREASED WORKLOAD DUE TO A SAGE PROGRAMMING ISSUE!!!!!  We couldn't possibly have foreseen that this change would happen to increase our workload so we haven't taken it into account when planning our resources.for year end and now it is too late.

    Why can't Sage go back to warning people, rather than enforcing?  I can make my own decisions and it is the responsibility of the business to make sure we have the required information - it is not up to Sage.  I'm an accountant and can make my own decisions with regards to what complies with legislation - I don't need Sage to do that for me.

  • 0 in reply to Caroline Reid

    Hi Caroline,

    I can appreciate that it has increased your workload if it's something you weren't expecting.

    If you feel confident enough to do so another suggestion would be to post everything on your non vatable tax code (T9) and then post a journal to account for the VAT. This will impact the VAT Return the same way.

    or again if you feel confident enough you could create your own tax code to bypass our checks. This guide will show you how the new codes impact the VAT Return >> Brexit - New import tax codes for use after 1 January 2021 - UK only (sage.com)

    Ian

  • 0 in reply to Ian C

    Thanks for the suggestions Ian, but I'm sure that you can see that finding a workaround is not really a solution to the problem!

Reply Children
No Data