Account Charges without VAT

Due to tax reasons, the Finance team needs to be able to create account charges without VAT, without issuing invoices as we are currently doing.

In order to allow it, the current workflow should accept VAT-exempt Fees and send a slightly different communication to clients. Moreover, the fields "fee name" and "invoice number" are requested to be updated to only accept values with a certain criteria, removing the current open input option. Quantum process and the balances workflows should be the same.

Prerequisites

Requirements are defined in this Product Requirement Document (PRD).

They can be summarized as:

• These new account charges should follow the same creation workflows we provide:
• Using a file to create them in bulk from Operations/Fees/Upload Fees.
• From the client's page, we can fill a form.
• A new email should be sent for this kind of account charges and the current one should not be sent.
• A reminder communication should be sent after 4 weeks from the due date on the account charge.
• The Fee Name should be selected from a predefined list.
• The Invoice Number (reference) should be calculated using a code depending on the Fee Name and the primary key (e.g. ACM0001).
• Quantum process should be similar to the current one.
• Ledger/Balance process should be similar to the current one.

Reference Documents

The reference document table contains links to relevant information for the RFC:

Reference	Document Location
PRD01	Product Requirement Document
TAN01	Technical Analysis

Problem Description

The Finance team needs to be able to deduct funds from clients balances for accounts charges (e.g. account maintenance, account opening, etc.) also, without issuing invoices and delivering an Account Charges Receipt to clients with a consecutive number, for the clients’ record.

Due to tax reasons, the capability needs to be implemented before the start of the next fiscal year (2023). Currently, these charges are collected from clients’ balance via Invoices created in Netsuite (then uploaded into BOS). These charges should not carry VAT.

This requirement comes from the back of a VAT investigation run by our Tax team. Clients were contacted by the local Tax authorities to record Ebury invoices for these matters - those invoices were not needed. The Tax team concluded the investigation that the services described before are not subject to VAT therefore an invoice (via Netsuite) should not be issued (at least for the vast majority of jurisdictions in which Ebury operates).

If we do not correct the situation, the current way of charging clients could cause potential tax penalties for VAT and further implications with the electronic reporting process for the local authorities. Depending on each country the potential sanction is calculated on a different basis from the annual turnover.

Background

Fee project allows us to charge fees to clients for anything related to a service. They are charged directly to the accounts and they are not linked with any product (Spot, Forwards, Drawdowns, etc.).

They are either created manually using a form:

Or they can be created in bulk

Also, they have their own section in the client side where we can see the due date, amount, period and if it is paid or not, among others.

When the invoice reaches the due date, we are going to receive a payment from the client to pay it, but we could receive the total or a partial amount. In the case of partial amounts, Finance could generate a credit note for the residual amount.

In certain cases the client will have a partial amount available on their balance to pay the invoice, and they can request to pay partially the invoiced fee and they will send the residual amount later, so reconciliation can send funds from balance to an invoiced fee.

Each time a Fee reaches maturity a debit movement is generated on the Fee ledger.

Each time a Fee is paid (partially or fully) a credit movement is generated on the Fee ledger.

Finally, these fees are sent to Quantum via TMS following the same process as other products and they are reflected in the client statements.

Solution

We need to add support for account charges (Fee model in BOS) but as some process/workflows are similar than the current one, the proposal is to reuse the current model adding a field in the existing model to identify if it is an account charge with or without TAX.

Once it is clear that the Fee model will be reused, next step is to clarify the changes in the different points of the requirements.

Quantum and Ledger/Balances

As these processes and workflows will be similar the current one, no changes are needed. This is the key to reuse the current Fee model, because in other case, it will be needed to replicate all these processes for this new Account charge. And how to this requirement should be delivered before of the end of the fiscal year, the development for this project should be minimized.

Fee Name and Invoice Number

The fee name should be one of a predefined list, this list should be in BOS and also, the list could be updated in the future. The invoice number (which is the reference) will be calculated according the fee name, because each fee name should have a Code Reference, plus a unique number separated by a hyphen, following the below structure: ABC-1234.

So the fee names list and their corresponding code will be stored in the database (New model: InvoiceType), currently, the fee names should be:

Fee Name	Code Reference
Payment Fees	TRI-XXXX
Annual Account Maintenance	ACM-XXXX
Blocking Certificate	BOC-XXXX
Pledge	PLG-XXXX
Ebury Account Maintenance	ACA-XXXX
Account Opening Fee	OFF-XXXX
Account Maintenance	ACR-XXXX
Balance fees	ACB-XXXX

*Additionally other fields can be added in this new model to provide more information for each fee name like Active/inactive, Type of invoice, Instrument, Frequence, Period, Internal item id, G/L account, Country and Comments. These fields will be not used in BOS for the life cycle of the account charge but will be useful in case of any report or auditory.

To adapt the creation to these changes, a new form for the manual creation should be created (the user will click on the form they need), where the fee name will be a dropdown of this list and the invoice number will be shown once the fee es created, because the unique number will be the PK

For the bulk creation, the uploaded CSV will contain a new column with a flag to provide if it is an account charge with VAT or not, and the backend will check if the fee name provided by the row without VAT will match with one element of the new model (The invoice number on these rows will be ignored).

Client Communication

The system will decide to use the current client communication or the new one using the new field added to the Fee model.

Reminder Email

This will be a new periodic task which check for the unpaid account charges if the due date was 4 weeks ago and then send a reminder email.

Service Ownership

New Service	Service Name	Service Owner
No	BOS	TFT Team

Alternatives

In order to provide an alternative solution aligned with the Technology Strategy, we would need to identify the domain for the Account Charges management. This domain will have strong dependencies with other identified ones (e.g., TMS, balances, ledgers and client communications), which are on different maturity levels of progress (or still lacking a defined domain strategy). The outcomes of these efforts can lead to different integration proposals, to which we can not currently have a definitive answer.

Moreover, the tight time constraints due to the potential fines exposure of the company to tax authorities justifies the need to reuse all existing workflows and components, leading to a tactical implementation (described in the previous section) that can be delivered safely within the current context.

As alternatives under the tactical solution:

To reuse the current Fee model, is to create a new model, but for this case, it is necessary to develop all the workflows for the life cycle and also replicate all the serializer and workflows for the Quantum processes; this will suppose an increase of the ETA of this project.

As alternative of the new model for the Fee Name, it is possible to use: - Hardcoded list: not recommended because a release is needed each time the list need to be udpated - List in BosSetting: not recommended because it is necessary two BosSetting (for the name and the code) or set a dict/json inside the BosSetting, this will add complexity to manage them.

Caveats

Right now, these new account charges will be allowed only for Ebury, Ebury Institutional Solutions and Ebury Solutions brand.

Operation

Finance team will create these new account charges, as the Fee model is being reused and the permissions and workflows are similar, all roles and protocols are already defined in the operations team side.

Security Impact

The proposed solution will add a new field in an existing model, create a new model and create a new email template, so it should not have any security impact.

Performance Impact

The performance impact on the BOS side should be minimum, as the account charges are already being assigned to the clients, with this change, there will be a different fee name (adding one or two queries to database in case of this kind of account charge) and a new process executed once every day to send the reminder email (one query to the Fee model).

Developer Impact

This should not have any impact to the developers, unless they need to work with the account charges directly.

Data Contracts

The account charges workflows will be similar than the current one, so it is fully compatible.

Deployment

First step is update the DB with the new field/model and create the new email templates.

Second step will be the update of the logic.

Dependencies

Invoice Fees to Clients through Main Fee Account EPIC (Done in 2019/2020)

Based on RFC Template Version 1.1