European Commission Treasury PDF

A blue screen with white text Description automatically generated European Commission Treasury Who we are ​​​​BUDG.C1 (Treasury Management) is in charge of managing the Commission\'s treasury, as well as the treasuries of the other entities for which the Accounting Officer of the Commission is re...

A blue screen with white text Description automatically generated European Commission Treasury Who we are ​​​​BUDG.C1 (Treasury Management) is in charge of managing the Commission\'s treasury, as well as the treasuries of the other entities for which the Accounting Officer of the Commission is responsible (such as the European Development Fund (EDF), the European External Action Service (EEAS), EU Trust Funds and a growing number of agencies). What we do  We execute all the payments and manage the treasuries for the above mentioned entities (more than 2.5 million payments per year). We also actively contribute to the establishment of policy instruments with regard to their funding and cash management structures (e.g. Next Generation EU, Common Provisioning Fund, etc.). ​​  Most of the EU revenue is represented by the EU own resources, which the Commission collects from Member States on the basis of the adopted budget. Other revenues arise from different sources including miscellaneous recoveries and contributions, fines, etc. The Commission has bank accounts with Member State Treasuries, Central Banks and Commercial Banks. Commission\'s cash resources are kept in the bank accounts held with Member States\' treasuries and central banks where the own resources are paid and are drawn solely for the purpose of executing payments. The cash needs of Commission\'s commercial bank accounts are covered by funds transferred to them from the accounts in the Member States, on a \"just-in-time\" basis to cover for payments execution. Commercial banks, where Commission\'s bank accounts are opened, are chosen by tendering procedures. These accounts are used in most of the cases for the execution of payments to beneficiaries, other than Member State governments. The Commission's bank accounts cannot be overdrawn. DG BUDGET serves as the central \'Treasury\' of the Commission, the European Development Fund (EDF), the European External Action Service (EEAS) and a number of other bodies to which the Commission provides central treasury services. Cash management, cash forecasting and reporting ​​​​According to [Article 86(2) of the FR](https://myintracomm.ec.europa.eu/corp/budget/Documents/financial-regulation-2018-optimised-en.pdf#ar86), the accounting officer shall ensure that his or her Union institution has at its disposal sufficient funds to cover the cash requirements arising from budget implementation within the applicable regulatory framework and shall set up procedures to ensure that none of the accounts opened with financial institutions or national central banks is in debit. To achieve this requirement, the Treasury Unit has implemented the following processes: - The [cash flow forecasting process] aims to estimate the medium/long term cash needs and determine the amount of cash to be called from Member States for the following month. - The [cash flow reporting process] aims to monitor the effective execution of the cash forecast on a weekly basis. In case of deviations, mitigating measures could be implemented to ensure critical payments are executed without delays. - The [weekly Member States cash transfer exercise] aims to align the cash balances of the Commission, kept across the Member States, in proportion to each Member State's contribution to the EU General Budget. - The [daily operational cash management exercise aims] to ensure all accounts opened with financial institutions or national central banks are in credit and the balances are protected in case of negative interests  environment​. Cash Flow Forecasting The main objective of the cash flow forecasting process is to ensure that sufficient funds are called from the Member States to cover the forecasted expenditure of the following months - in particular during the first quarter of the year where a specific treasury cash flow statement justifies the anticipated request for own resources. The forecasting process is a monthly process based on the following sources of information: - Previous month cash balance; - Budget, amending budgets and draft amending budgets; - Revenue own resources : custom duties, GNI, VAT - Revenues non-own resources : fines, third country contributions, EFTA...; - Budgetary and non-budgetary payment execution; - Forecast of expenditure of main expenditure DGs dealing with the structural funds (REGIO, EMPL and AGRI) representing 60% of the outflows; - Forecast of other expenditure based on past year budget implementation; This will be used in a model for the simulation of the possible 12ths to be called leading to a final decision about it. The final output will be the base for the call for funds to be sent to Member States before mid-month. Member States own resources contributions related to GNI-VAT will be paid the first working day of the following month. The monthly forecasts required for the treasury management are produced within the system SAP Business Planning Consolidation (BPC) solution.​ Cash Flow Reporting To avoid any cash shortage, the weekly cash flow reporting aims to monitor the execution of treasury against the forecasted revenue and expenditure. The cash flow reporting process is based on the following sources of information: - Last month cash forecasting exercise; - Own resources and non-own resources revenue collected; - Budgetary and non-budgetary payment execution; Deviations are analysed and reported to management. In exceptional cases, corrective actions may be required. Member States Cash Transfer According to Article 14.4 of the [Council Regulation (EU, Euratom) 2016/804](http://data.europa.eu/eli/reg/2016/804/oj) of 17 May 2016 amending Regulation (EU, Euratom) No 609/2014 on the methods and procedure for making available the traditional, VAT and GNI-based own resources and on the measures to meet cash requirements, 'The difference between the overall assets and the cash resource requirements shall be divided among the Member States, as far as possible, in proportion to the estimated budget revenue from each of them.' The Member States Cash Transfer exercise is a monthly cash management exercise aiming to align the cash balances of the Commission, kept across the Member States, in proportion to each Member State's contribution to the EU General Budget, the budgetary key. To this purpose, the Treasury section of Unit C1 calculates the target balances according to their contribution to the EU General Budget (using Member State's budgetary key as a pro rata coefficient) and executes transfers of funds between the Own Resources accounts twice a month. The first exercise is conducted to execute transfers with valued date second working day of the month after the European Agricultural Guarantee Fund (EAGF) payments have been processed. The second exercise is conducted to execute transfer with value date around tenth working day of the month. This involves FX conversion of balances in foreign currencies (SEK, DKK, PLN, CZK, HRK, HUF and RON) to EUR. The average balances of the Own Resources accounts are monitored regularly to see if adjustments are needed to maintain as much as possible the proportional share of the Member States keys. Daily Cash Management The Treasury of the Commission executes the majority of the payments from Commercial banks whereas the available cash is kept at the Central Banks and the Own Resources bank accounts in each of the Member States. Given that the funds kept at the Member States can be made available with a notice of 3 working days, the Treasury of the Commission replenishes the Commercial banks, by debiting the Central Banks / Own resources accounts, with a value date of 3 working days ahead of the date the payment instruction. For the above reason, the payments are executed from the Commercial bank accounts with a value date of 3 working days ahead of the date they are validated by the Authorizing Officer. Bank accounts opened in the name of the Commission/EEAS/EDF may not be overdrawn.  Payment Processing ​​​  Payment Orders validated by Authorizing Officers in ABAC Workflow are automatically channelled (in SAP) to the Commission\' Treasury (DG BUDG), which sends the payments for execution to the bank. DG BUDG Treasury processes \"payment runs\" at least twice a day, to execute the payments of several entities including the Commission, EDF and EEAS. The payment run generates payment instructions which are sent to the banks via SWIFT for the execution of the credit transfers to the beneficiaries. Specific \"payments runs\" are also executed each day in order to send Local Payment Instructions (LOCPAY) to the Delegations for their small administrative payments that need to be executed locally. A diagram of a company\'s payment process Description automatically generated What are the steps in the payment execution? 1\) Payment initiation The Initiating Agents introduce all payment details in ABAC (or in any other Local tool), such as: - Beneficiary -- (LE) - Bank Account (BA) - Payment Currency and amount - Payment Description (max 129 characters) - field \"message to beneficiary\" of the Payment Request or automatically filled in from the fields \"date\" and \"Supplier reference\" of the invoice - Budget Line 2\) Payment authorisation (after verification by the Verifying Agent) The payment is validated by the Responsible Authorising Officer (AOD) in ABAC. 3\) ABAC -- SAP interface The authorized payment is automatically transmitted from ABAC to SAP, ready to be executed by the central Treasury (BUDG). 4\) Payment run The central Treasury sends the payment for execution to the banks. System generated SWIFT Messages (payment instructions), containing all the payment details, are transmitted to the EC banks for this purpose. 5\) Payment execution date The bank execution value date instructed to the bank is: validation date by the AOD + 3 business days. The bank executes the payment and debits the Commission\'s bank account at that date. 6\) Payment received by the beneficiary - For SEPA payments the amount paid is credited on the beneficiary account within one day from the execution date (= date of debit on the EC\'s bank account). In practice this means that the beneficiary account is credited, at the latest, four business days (3 + 1) after the validation by the AOD in ABAC; - For all the other payments (non EEA or in other currencies than EUR), the date for the credit on the beneficiary bank account may take longer, depending on the country and/or the payment currency and/or the beneficiary\'s bank.  To prevent possible issues (blockages, delays, returns) in the payment execution, follow these simple stepsA colorful rectangular card with text Description automatically generated with medium confidence Payment methods What payment methods can be used to pay the beneficiary? Payments can be made from the Central Treasury by bank credit transfer or by cheque. As a pre-requisite for authorising a payment to be executed by the Treasury, the legal entity (LEF) and the bank account (BAF) containing the banking details of the beneficiary must be duly recorded in the accounting system (ABAC). **Bank credit transfer**: priority should always be given to this method of payment. **Cheques**: it is to be noted that this method of payment implies that a bank (located in Europe) will issue a cheque and send it via a standard post mail to the beneficiary\'s address. A BAF with payment method CHQ should be created and linked to the LEF, in this case. **The use of this payment method must be limited to exceptional cases when credit transfer is not possible for justified reasons.** [Imprest accounts](https://myintracomm.ec.europa.eu/corp/budget/treasury-accounting/treasury/Pages/imprest-accounts.aspx) payments can also be made by **debit card** or **direct debit**, subject to specific conditions established by the Accounting Officer. How does the choice of currency impact the payment execution? The choice of the payment currency is normally made at the time a contract or agreement is signed. For this reason, before signing the contract, the signatory should make sure that the beneficiary\'s bank is able to receive payments in such currency from a bank located in the EU. This may require a EUR correspondent bank to route the EUR payments to a beneficiary\'s bank outside the Euro zone. Payments are executed in the currency (paying currency) indicated in ABAC by the AOD service and transmitted to the bank in the Swift payment instruction. If the beneficiary\'s bank account is in another currency (local currency for example) it is the responsibility of the beneficiary to request/authorise his bank to convert the funds received and credit his bank account. Please note that ABAC Workflow allows indicating a paying currency different from the posting currency. Currency conversion differences Are there differences in case of a fix or a fluctuant exchange rate? Payments in foreign currency generally give raise to exchange differences because the Commission needs to buy the foreign currency (unless it has it already available) to execute the payment. For some currencies, that have fix exchange rates with the Euro, no exchange differences are generated but for the vast majority of foreign currencies that have fluctuant exchange rates, exchange differences normally need to be booked in the accountancy. When a payment request in foreign currency is generated in ABAC, the counter value in EUR is determined on the basis of the InforEuro exchange rates of the current month. InforEuro provides purely indicative exchange rates and serves as a reference for accounting purposes. Banks use market exchange rates and debit the EC bank account for the counter value of the payment in foreign currency. Credit to the beneficiary\'s account -- timing Payments within the SEPA area What does SEPA stand for? SEPA is the Single Euro Payments Area. It is a payment-integration initiative of the European banking industry for the simplification of bank transfers denominated in Euro, with the aim of improving the efficiency of cross-border payments in Euro within the European Economic Area and making them as easy as domestic payments.​ What are the main characteristics of the Single Euro Payments Area? - Euro as the single currency for payment transactions (regardless of the account currency). - Uniform operating procedures, including exclusively electronic processing with an **IBAN** and a **BIC** for identifying accounts and banks. What are the requirements for a SEPA credit transfer? - The payment is in euro. - The beneficiary\'s account number must be entered in IBAN format. - The beneficiary\'s bank is identified by the valid BIC code. - Number of characters carried with remittance information: max 140 characters (out of which only 129 can be used). - Assignment of bank charges as \"SHA\" (the beneficiary and the remitter pay the fees of their respective bank). - Executed within one business day Are there any advantages of having a SEPA credit transfer? - The payment (without conversion) is always delivered to the beneficiary no later than on the following business day. - The transfer amount is not limited. - The entire transferred amount is credited to the beneficiary\'s account; potential fees are settled separately. - The payment format contains an additional text field (end-to-end reference) in which the payer may send additional information. This text is delivered without alterations from the payer to the payee. Payments outside the SEPA area Payments outside the SEPA area can be transferred directly from the EC banks to the beneficiary\'s bank, when there is a direct link between the two banks, or via a \'correspondent bank\' if the two banks are not business partners. The time needed to receive the payment can vary from 2 - 3 days to several days, depending on the country of the beneficiary, the routing via correspondent banks and the efficiency of the banking system in the beneficiary\'s country. Bank execution value date, payment delayed What does the field \"bank execution value date\" indicate and how is it filled in? The field \"bank execution value date\" in ABAC indicates the date when the payment request was executed by the EC bank. It is filled in automatically by SAP as soon as the EC bank account is debited and the bank statement is transmitted and reconciled in the EC accountancy. In total, this may take up to 5 business days from the date of the payment authorisation. In which event can the execution of a payment be delayed? In some cases the execution of certain payments can be delayed due to unexpected circumstances such as bank details insufficient for the bank to apply the payment (in this case the bank normally contacts the EC Treasury and asks for additional information), specific country requirements, bank compliance screening, missing or erroneous bank circuits etc. Due date How can I set a different execution value date in ABAC? By default, the bank execution value date quoted in the payment instruction (Swift message) sent to the bank is: validation date by the AOD + 3 business days (D+3). If the payment deadline is still distant in time, the initiating agent/AOD may decide to delay the execution date by setting a later date in the field \"due date\" in ABAC (provided that this date is after D+3). As a result, the payment will not be sent to the bank till \"due date\" less 3 business days. Unless specific legal constraints make it mandatory, financial officers are advised to leave this field blank. Payments on \"budget anticipé\" What should I pay attention to when instructing payments on the \"budget anticipé\"? As from 1st December payments can be booked on anticipated administrative appropriations (commitments on anticipated environment). However, these payments will have by default a \"due date\" of year N+1. If they need to be paid in year N a specific action in ABAC Workflow is required: the field \"no overwrite\" must be put to blank, which will result in an immediate execution in year N. Payments on N+1 appropriations booked in December N for which this field is left activated will remain suspended and will be executed in January N+1.  Bank account reconciliation  24/06/2024 18:50  (https://myintracomm.ec.europa.eu/corp/budget/treasury-accounting/treasury/Pages/bank-account-reconciliation.aspx) (https://myintracomm.ec.europa.eu/corp/budget/treasury-accounting/treasury/Pages/bank-account-reconciliation.aspx) ​​​​​ The execution of payments authorized by AOD may eventually not be finalized for reasons including: \"block ​by the payment run\"​, \"not execution by the bank\", or \"return after execution\", either by the banks or by the beneficiary. In such events, a **VR** (virement à re-imputer) file is created to notify the spending service that the payment needs to be re-initiated. After reception of this note (and correction of the problem that caused the return of the payment), the service is allowed to establish a negative payment (for budgetary payments made during the current financial year) or to repay by debiting the GL account 49970000 (for payments posted in a previous financial year or to a Hors-Budget account).  Different events can block or delay the payment execution - consequences What events can generate blockages or rejections at the payment run? 1. Wrong currency and/or bank account: sometimes the beneficiaries have more than one bank account, expressed in different currencies; the initiating agent may select a beneficiary\'s account which is in a country using a different currency from the one of the payment. In some cases, this is not a problem (e.g. EUR paid in a Danish account opened in EUR), but in other cases (e.g. Indian Rupees paid in Belgian bank account) this is technically not possible and the payment is at risk of  being blocked by the payment run (or rejected by banks). It is therefore crucial for the initiating agent to choose the right bank account and currency for the specific payment. 2. Currencies that cannot be used for international payments: payments initiated in these currencies may be blocked by the payment run or rejected by banks. Please consult InforEuro​ website. 3. For EEAS delegations: initiating agent choosing the wrong payment method, flagging \"local\" instead of \"central\" payment or vice-versa. 4. Bank account blocked: the beneficiary bank account is blocked by DG BUDG (Third-Party File section) after the validation by the Authorizing Officer and before the payment run execution. 5. Blockage request of the initiating service: in exceptional cases, a payment can be blocked before the payment run, within a very limited period of time from authorisation, at the request of the AOD. The very limited timing and the exceptionality of this kind of request must always be considered before submitting such a request to [BUDG PAYMENT RUN​](mailto:%[email protected]). In any case, there is no guarantee that a payment can be blocked by the Central Treasury (BUDG) after it is authorised by the AOD. In all these cases, the payment request transmitted by ABAC to SAP will not be executed by the payment run. The Central Treasury, in charge of the payment run execution, will therefore set up a VR file to inform the initiating agent that he has to re-initiate a correct payment request. Most frequent reasons for payments returns For which reasons are payments sometimes returned by banks? The most frequent payment return reasons are: - **Beneficiary bank account is closed** Initiating agents are advised to always check with the beneficiaries if their bank details are still valid, when preparing a payment, especially if a long time has passed after the bank account was encoded in ABAC and the last payment was executed. - **Incorrect bank details** This can be linked to the fact that the beneficiary bank has merged with another bank/ changed denomination/ changed the numbering of its accounts, etc. and, consequently, the bank details previously encoded are not valid anymore. This could also be connected to a change in the account holder\'s details (e.g. denomination, legal form). - **The beneficiary cannot identify the reason for the payment or considers that the amount or part of the amount is not due** In this case, he may request his bank to return the payment. - **Details provided do not allow the bank to finalise the payment\ ** - **Bank reachability issues** The beneficiary\'s bank is not reachable via the international banking network (no EUR correspondent for the beneficiary\'s bank exists). - **Compliance screening by banks** See specific section \"compliance\". - **Use of wrong bank account** More bank accounts may be linked to the same beneficiary. In such case it is important to select the bank account denominated in the same currency as the one of the payment. If this selection is incorrect, this may give rise to the return of the payment or to the credit of the amount on a wrong bank account. Follow-up of exceptions, inquiries, investigations Certain payments may give rise to questions, inquiries, or investigations at different stages of the execution process. These can be linked to a variety of potential issues including: - bank reachability issues - specific requirements for certain countries - compliance issues - funds not yet received by the beneficiary - the beneficiary cannot apply - bank charges - request of clarifications on returned amounts, etc In such events, a LP (litige de paiement) file is generated and the inquiry is followed up in cooperation with banks, beneficiaries, and initiating services. A diagram of a diagram of a company Description automatically generated with medium confidence How to help ensure correct execution of payments linked to \"difficult countries\", country-related requirements, compliance issues What can I do to prevent delays and rejections of payments? Banks\' compliance screening Certain countries are subject to different types of international sanctions. Other types of sanctions against specific entities (companies, persons, beneficiary banks...) also exist in the context of the fight against terrorism, anti-money laundering, etc. If any payment is directed to such countries or entities, banks ask to justify the payment, to provide additional documents and information related to the beneficiary. This can also happen because the beneficiary name is similar to a \'sanctioned entity\' or a word or acronym in the payment reason is somehow similar or linked with a sanctioned country or entity. It may happen that entities are not sanctioned by the EU, therefore they do not raise an alert in ABAC, but they are subject to other countries\' sanctions (e.g. USA, ONU). Payments directed to such entities are likely to be rejected or even blocked by the banking system, since banks have to comply with any national or international sanction scheme. Additionally, international sanctions are subject to daily modifications, according to the evolution of the geo-political situations. Before entering into business with certain contractors or before authorising any payment, the AOD should always verify that the contractor\'s name and the contractor\'s country are not included in any list of sanctioned entities/countries. Message transmitted to the beneficiary The content of this information comes from the \"message to beneficiary\" field of the P.R. (payment request) or it is filled in by default from the fields \"date\" and \"supplier reference\" of the invoice. To streamline the payment process, minimize the risk of delays and rejections resulting from banks\' verifications on sanctions compliance monitoring, we recommend to consider carefully the content of this field, in particular quoting a short and clear description of the payment reason. Acronyms should possibly be avoided as they may result suspicious to banks\' compliance departments and lead to unnecessary requests for clarifications/explanations or payment rejections. To ensure that the payment is properly identified by the beneficiary, it is necessary to include in the field \"message to beneficiary\" all the relevant payment information such as the full name of the project, contact person details, invoice number, etc. Which countries need additional/specific information in order to properly execute the payments? Country requirements The European Commission sends payments to beneficiaries in almost every country in the world. However the performances of bank systems are different depending on the country/region. This might have an impact on the execution since payments to certain countries (in particular outside the EU) may take a longer time to be executed and require, in some cases, additional efforts and follow-up. Certain countries impose the supply of specific information or details to allow local reception of the payments. In the currency guide, provided by one of the EC\'s banks and broken down by country, you will find such specific requirements. The required information must be entered in the field \"message to beneficiary\". Bank charges, charges on returned payments In what situations can banks levy fees on the amount paid? Commission\'s banks do not levy any fees on the amount paid. However, beneficiaries banks or their correspondents may levy bank charges to their clients, depending on their standard conditions or specific conditions agreed with their clients. Who incurs the cost of the payment? All Commission\'s payments are instructed with a \"SHA\" (shared) clause, meaning that each party of the transaction bears its own charges, i.e.: the Commission assumes the cost of its own bank while the beneficiary bears the charges debited by its bank and its correspondents. The contracts signed with suppliers and third parties should always contain an article to inform them explicitly that Commission\'s payments contain the \'SHA\' clause. If the payment is channeled via an intermediary bank (when our bank has no direct connection with the beneficiary\'s bank), the intermediary institution may deduct its charges from the amount of the transfer. Are bank charges levied when a payment is returned? When a payment is returned, bank charges might be deducted by banks from the returned amount (this happens mainly in the case of non-SEPA payments). The bank charges related to returned payments are incurred by the EC, even though the amount finally made available to the AOD service for repayment is equal to the original amount. Imprest accounts ​​​What is an Imprest Account? As defined in [Article 88 of the Financial Regulation](https://myintracomm.ec.europa.eu/corp/budget/Documents/financial-regulation-2018-optimised-en.pdf#ar88), Imprest Accounts may be set up for the payment of expenditure where, owing to the limited amounts involved, it is materially impossible or inefficient to carry out payment operations by budgetary procedures. Imprest Accounts may also be set up for the collection of revenue other than own resources. Imprest Accounts (Instructions of the Accounting Officer). These Imprest Accounts are generally managed either by a Commission\'s Directorate-General, or by EEAS\'s Delegations, or by Representations of the Commission. An Imprest Account is therefore used to execute payments for [administrative expenditures](https://myintracomm.ec.europa.eu/corp/budget/annual-budget/budget-structure/administrative-expenditure/Pages/administrative-expenditure.aspx), up to 60.000 EUR (Instructions of the Accounting Officer), on the basis and within the limit of prior budgetary and legal commitments, signed by the Authorising Officer. However, in the field of crisis management aid and humanitarian aid operations within the meaning of article 88 of the Financial Regulation, Imprest Accounts may be used without any limitation on the amount, while respecting the level of appropriations decided by the European Parliament and the Council on the corresponding budget line for the current financial year. The creation of an Imprest Account, the appointment of an Imprest administrator, and the amendment of its operating terms shall be the subject of a decision by the Accounting Officer, based on a duly substantiated proposal from the Authorising Officer (Instructions of the Accounting Officer). This decision shall set out the respective responsibilities and obligations of the Imprest administrator and of the Authorising Officer. The appointment of an Imprest administrator [Imprest ad​ministrators](https://myintracomm.ec.europa.eu/corp/budget/financial-rules/budget-implementation/financial-actors/Pages/imprest-administrator.aspx) shall be chosen from Officials or, should the need arise and only in duly substantiated cases, from other members of staff. Imprest administrators shall be chosen on the grounds of their knowledge, skills, and particular qualifications as evidenced by diplomas or by appropriate professional experience, or after an appropriate training programme (Instructions of the Accounting Officer). In exceptional circumstances and for the purposes of continuity of service, the duties of an Imprest administrator in the Union Delegations may be performed by staff of the Commission. Under the same conditions, the staff of the EEAS may be designated as Imprest administrators for the Commission\'s Imprest accounts (Instructions of the Accounting Officer). Operating rules of Imprest Accounts The Accounting Officer is responsible for the opening and the closing of bank accounts, as well as for the subdelegation of the signatures for the Imprest Accounts. Based on a monthly closure sent by the Imprest administrator, the Accounting Officer will replenish the bank account of the Imprest Account. According to the instructions of the Accounting Officer, the decision setting up an Imprest Account; appointing an Imprest administrator and amending the operating terms for an Imprest Account shall specify in particular: - the identity of the appointed Imprest administrator; - the maximum amount which may be provided and its purpose; - details identifying a bank account opened/to be opened in the name of the Institution and the names of the authorised signatories; - the nature and maximum amount of each item of expenditure which may be paid by the Imprest administrator to third parties; - if applicable, the maximum amount of revenues which may be cashed into the Imprest account; - the frequency with which supporting documents must be produced; The Authorising Officer shall ensure that: - priority is given to the use of budgetary procedures when there is access to the central computerised accounting system; - Imprest Accounts are used only in substantiated cases. Payments from Imprest Accounts may be made by bank credit transfer, direct debit, cheque or other means of payment, including debit cards, in accordance with the instructions laid down by the Accounting Officer. Responsibility of the Imprest administrator According to the [article 95 of the Financial Regulation](https://myintracomm.ec.europa.eu/corp/budget/Documents/financial-regulation-2018-optimised-en.pdf#ar95), an Imprest administrator officer shall be liable to disciplinary measures and payment of compensation, as laid down in, and in accordance with, the procedures in the Staff Regulations. An Imprest administrator may in particular become liable as a result of any of the following forms of misconduct on his/her part: - losing or damaging funds, assets, or documents in his/her keeping; - not providing proper supporting documents for the payments he/she has made; - making payments to persons other than those entitled to such payments; - failing to collect due revenue. Controls of the Imprest Accounts The Imprest administrator shall keep track of: - the funds at his/her disposal, in cash and at the bank, - payments made, - amounts received. Statements shall be accessible at any time to the Authorising Officer. A monthly closure shall be sent by the 15th of the following month together with supporting documents by the Imprest administrator to the Accounting Officer. The Accounting Officer shall carry out controls, or have them carried out by a staff member from his/her department. These controls shall as a general rule be effected on the spot and, when necessary, without warning, to verify the existence of the funds allocated to the Imprest administrators. The Accounting Officer shall communicate the findings of these controls to the Authorising Officer. ([art. 89 of the Financial Regulation](https://myintracomm.ec.europa.eu/corp/budget/Documents/financial-regulation-2018-optimised-en.pdf#ar89)). Administrative payments in EU delegations (EEAS) What are the differences between central and local payments? What are the implications? Central payments are processed centrally by the Treasury via the \"payment run\" and sent to the banks of the Institutions for execution. This process is applicable for the majority of the payments. This is highly automated and starts immediately after the validation in ABAC by the AOD. Local payments are also treated by the Treasury via the \"payment run\" but executed from the local bank account(s) of the EU Delegations, after reception and in accordance with a specific authorization (LOCPAY message) issued by the Treasury. Local payments are used for execution of the administrative payments of EU Delegations As a general rule, the distinction between central and local payments is driven by the following criteria: TABLE: EU DELEGATIONS - CENTRAL VERSUS LOCAL PAYMENTS     Authorisation of Expenditure (AoE) Via the AoE, an Authorising Officer from the Commission or the EEAS HQ may request an EU Delegation to execute a payment locally, when a payment to a beneficiary in a given country cannot be executed centrally. The AoE has to be created in ABAC explaining the reason justifying the local execution of the payment, and linked to the budgetary commitment. The Authorising Officer validates it. The services of the Accounting Officer evaluate the relevance and the justification of the request (e.g. it is impossible or inefficient to pay centrally), and gives its approval, or refusal, via a visa in ABAC. Following approval by the Accounting Officer, an automatic e-mail is delivered to the Imprest Account holder of the concerned Delegation, authorising him to execute the payment(s) locally once validated by the relevant Authorising Officer.