Différences

Ci-dessous, les différences entre deux révisions de la page.

--- en:wiki:compta:sepa [2025/06/24 19:16] – créée - modification externe 127.0.0.1
+++ en:wiki:compta:sepa [2026/10/23 21:31] (Version actuelle) – Automatic push translation eneuville
@@ Ligne 1: / Ligne 1: @@
 ====== SEPA Export ======
-FIXME A1 proofreading not yet effective for this page. In the meantime, you can ask any questions on the [[https://forum.gestan.fr|forum]].
-Gestan automatically generates XML files intended for direct debits or SEPA transfers.
+Gestan allows you to generate the XML files to be sent to your bank, so that you can carry out:
+  * direct debits for amounts owed to you by your customers,
+  * automatic payments of amounts you owe to your suppliers.
-Transmitting a SEPA standard file to your bank allows you to collect the amounts owed to you from several customers at once, or to pay what you owe to all of your suppliers.
-===== Prerequisites =====
+===== Setting up direct debits from your customers =====
-When you want to debit your customers via SEPA direct debits, you must first obtain an ICS (SEPA Creditor Identifier), to request from your referent bank (in France, this is the Banque de France). Register this ICS in the [[en:wiki:parametrage:general:entreprise#address_and_identification|general parameter]] of Gestan.
+To collect payments from your customers via SEPA direct debits, you must first obtain an ICS (SEPA Creditor Identifier), which you can request from your reference bank (in France, this is the Banque de France). Enter this ICS in the [[en:wiki:parametrage:general:entreprise#onglet_juridiquefiscal|general settings]] on Gestan.
-Then, have each of your customers sign a SEPA mandate, and record for each customer:
+Then have each of your customers sign a SEPA mandate: {{fr:wiki:compta:exemple_sepa_1.pdf| SEPA Mandate Example 1}} - {{fr:wiki:compta:exemple_sepa_2.pdf| SEPA mandate example 2}}. You can have this mandate signed by post or electronically.
-- their banking information in the Commercial information tab of the contact sheet:
+Once the mandate has been signed, open the customer’s record.
-   * the BIC and the IBAN.
-- their SEPA information, via selection of the direct debit payment method and a click on the parameter entry button below:
+First, enter their BIC and IBAN in their record, then select “Direct Debit” as the payment method, and enter:
+  * the date the mandate was signed.
+  * the unique mandate reference number (RUM). This is a 35-character identifier.
-   * the date of signature of the mandate. Theoretically, a mandate automatically expires after 36 months of inactivity.
+{{fr:wiki:compta:sepa_01.png?nolink|}}
-   * the unique mandate reference number (RUM). This is a 35 character identifier.
-{{:fr:wiki:compta:sepa_1.jpg?nolink|}}
+The ICS/RUM combination must be unique for each contact. You can use a single RUM for all transactions for the customer, regardless of their nature. It is therefore possible, for example, to use as the RUM a description corresponding to the service you provide to the customer, or your company name, together with the date and time of signing, for instance (for your customer, this will be more useful than an obscure code they might find on their bank statement).
-The ICS/RUM pair must be unique for each contact. Apparently you can use a single RUM for all operations for the customer, regardless of nature. You can, for example, use as RUM a wording corresponding to the service you provide to the client, or your company name, with the date/time of signature, for example (for your client, this will be more useful than an abstruse coding which he will find on his account statement).
+📍In theory, a direct debit mandate automatically lapses after 36 months of inactivity.
-===== Using the screen =====
-//**Access:** Accounting -> Export -> SEPA Export //
+===== Generate a direct debit file =====
+//**Access:** Accounting -> Export -> SEPA Export//
-{{:fr:wiki:compta:sepa_01.png?nolink|}}
+{{fr:wiki:compta:sepa_02.png?nolink|}}
-Open the screen, select a **Movement** type and a date range.
+On the screen, select the **bank** for which you wish to carry out the transaction.
-The **Account** is the bank account for which you want to carry out the transaction.
+The **transaction date** (the date on which the direct debit is requested) is automatically set to the day after today’s date. This is because some banks do not accept direct debits on the same day. You can change this if your bank allows it.
-The **operation date** (date on which the direct debit operation is requested) is pre-displayed the day after today's date. In fact, some banks refuse direct debits on the current date. You can change it if your bank accepts it.
+Select ‘Direct debit’ as the type of **transaction** if you wish to generate a direct debit file for your customers, and the **Transaction type** (Core, B2B, or automatic).
-The **Add ID** check mark allows you to integrate the part number into the Nature label. Thus, the "Nature" labels of the parts are prefixed with Cxxxx, with xxxx= invoice number.
+The **Add ID** allows you to include the document number in the ‘Description’ field. Consequently, the ‘Description’ fields for documents are prefixed with Cxxxx, where xxxx= s the invoice number.
-The **Not due** check mark allows you to include in the delivery, or not, the parts which are due on the specified **operation date**.
+The **Not due** allows you to choose whether or not to include documents that are past due as at the **specified transaction date** .
-The checkmarks **Adjusted**, **All modes**, and **Unpaid** should always be unchecked, because they allow, for the first, to also see the adjusted parts, for the second to see the parts whatever either the payment method (not only for SEPA direct debit) and for the third to see invoices marked as unpaid.
+Select a date range.
-When you click on the **Show** button, the screen is populated with the corresponding parts. For example, if you select the "Direct Direct Debit" type, all direct debit invoices not yet paid for the selected date range are displayed, with the corresponding SEPA information.
+The **Paid**, **All modes**, and **Unpaid** should always be unchecked, as the first option allows you to view settled invoices as well, the second allows you to view invoices regardless of the payment method (not just for SEPA direct debits), and the third allows you to view invoices marked as unpaid.
-The screen pre-selects the parts that should be part of the shed. Excluded from the pre-selection are those which have already been paid, or which are missing banking or SEPA information.
+When you click on the **Display**button, the screen is populated with the relevant documents. For example, if you select the “Direct Debit” type, all direct debit invoices within the selected date range are displayed, along with the corresponding SEPA information.
-:TIP: Any abnormal invoices are displayed in red.
+The screen pre-selects the documents that should be included in the remittance. Those that have already been paid, or for which bank or SEPA details are missing, are excluded from the pre-selection.
+:TIP: Any invoices with errors are displayed in red.
-==== Use case: partial payment ====
+==== Generating the XML file ====
-Let's take the following case: your customer asks you for a split payment for your 1000 euro invoice.
+The **Export** button generates a SEPA_xxxxxx_[date]_[time].txt file, which is saved in the **output directory**. You will need to send this file to your bank, usually via the bank’s backend system.
-If you had accepted, and agreed for example on two payments of 500 euros, simply modify the amount including tax in the table. This way, the export file will include the correct amount to take.
+It is strongly recommended that you print the corresponding FAC5 report to keep a record of the transfer requests issued. This is because, until you have marked an invoice as paid, you can submit a transfer request (you might submit this request twice).
-However, you will need to remember (to do this, you can record an anomaly on the invoice), when you will receive the account statement from your bank, which generally has a single line for the entire direct debit file, which your customer has given you. paid 500 euros, not 1000. When you make a new SEPA file, the incompletely paid invoice will appear in the list, for the residual amount, here 500 euros.
+At the end of processing, the programme will ask you if you wish to confirm the submission: this involves saving the SEPA remittance slip number, which will be incremented by 1 for the next submission.
+==== Case of partial payment ====
+Let’s consider the following scenario: your customer asks to pay your €1,000 invoice in instalments.
+If you have agreed to this, and, for example, agreed on two payments of 500 euros, simply amend the total amount (including VAT) in the table. This will ensure the export file contains the correct amount to be debited.
+However, you will need to remember (you can do this by noting an anomaly on the invoice) that when you receive your bank statement – which usually contains a single line for the entire direct debit file – your customer has paid you 500 euros, not 1,000. When you create a new SEPA file, the partially paid invoice will appear in the list for the remaining amount, in this case 500 euros.
 ==== Checking recurrence ====
+The SEPA standard includes the concept of recurrence: when this standard was first implemented, it was necessary to process separately customers being debited for the first time, those being debited for the last time, as well as those debited on a recurring basis and those on a one-off basis.
-The SEPA standard includes a notion of recurrence: at the start of the application of this standard, it was necessary to treat customers debited for the first time, the last time, as well as those debited on a recurring basis and those on a one-off basis separately.
+Customers being debited for the first time, but who are to be debited on a recurring basis thereafter, had to be processed using the ‘FIRST’ method. The process then had to switch to ‘RECUR’, followed by ‘FNAL’ for the final debit. For a one-off debit, the method is ‘OOFF’.
-It was necessary to collect in FIRST customers who were withdrawn for the first time, but who must subsequently be withdrawn on a recurring basis. And you then had to go to RECUR, then to FNAL for the last sample. For a one-off collection, it is OOFF.
+Normally, the sequence of FIRST followed by RECUR is no longer mandatory: you can submit your requests directly as RECUR. However, some banks may still adhere to this standard.
-Gestan calculates the probable recurrence: if an invoice precedes the invoice concerned is found with a direct debit payment method, the recurrence is set to RECUR, otherwise it is set to FIST. It goes without saying that checking the recurrence and reporting FNAL or 00FF samples must be carried out by the operator.
+Gestan Calculates the likely recurrence: if an invoice preceding the invoice in question is found with direct debit as the payment method, the recurrence is set to RECUR; otherwise, it is set to FIRST. However, the operator must check the recurrence status and flag any FNAL or 00FF direct debits.
-The context menu of the table allows you to pass a sampling selection to the chosen recurrence.
+The table’s context menu allows you to set a selection of direct debits to the chosen recurrence type.
-{{:fr:wiki:compta:sepa_02.png?nolink|}}
+{{fr:wiki:compta:sepa_03.png?nolink|}}
-:TIP: Sequencing in FIRST then RECUR is no longer mandatory: you can place your requests directly in RECUR
+<WRAP center round box>
-==== Obtaining results ====
+=== The SEPA standard ===
-The **Export** button generates a SEPA_xxxxxx_[date]_[time].txt file produced in the **output directory**. You will need to transmit this file to your bank, generally via the bank's backend.
+The SEPA (Single Euro Payments Area) standard is a European standard that harmonises credit transfers and direct debits in euros. It enables financial transactions to be carried out throughout Europe: the 27 Member States of the European Union, the member countries of the European Economic Area (Iceland, Liechtenstein, Norway), and certain third countries (the United Kingdom, Switzerland, Monaco, San Marino, Andorra and the Vatican).
-It is strongly recommended to edit the corresponding FAC5 report, in order to keep a trace of the transfer requests issued. Indeed, as long as you have not indicated that an invoice is collected, you can make a transfer request (you could make this request in duplicate).
+It is based on XML files compliant with the ISO 20022 standard, which enable the following:
+  * SEPA credit transfers (SCT – SEPA Credit Transfer): transfers from one account to another within one working day.
+  * SEPA instant credit transfers (Inst-SCT): transfer of funds in under 10 seconds (now the mandatory standard for both sending and receiving payments for all European banks).
+  * SEPA direct debits (SDD – SEPA Direct Debit), in the Core version (for private individuals) and the B2B version (for businesses): used to settle recurring invoices.
-At the end of the processing, the program will also ask you if you want to validate the remittance: this will simply consist of recording the SEPA slip number, which will be incremented by 1 at the next remittance.
+Since 2026, the migration to ISO 20022 has required a strict structure for postal addresses in financial transactions to enhance compliance.
+The history of this standard is remarkably chaotic: until 2014, banks used the CFONB format (still used for certain transactions). It was a flat, simple and readable file. However, the European authorities – in this case the EPC (European Payments Council) – decreed that a more complicated system was needed, and created the SEPA format, based on XML, which was very much in vogue at the time.
-<bootnote>
+Very poorly designed from the outset, the SEPA standard was amended as things progressed, with the major absurdities being removed in response to protests, but its adoption, originally scheduled for 1 February 2014, had to be postponed by six months. Our developers still remember the hair they lost back then!
-** The SEPA standard **
+The result is that anyone with your account number can include it in a direct debit file and thus debit your account, as banks do not carry out SEPA mandate checks. You will only be aware of the transfer once it has been carried out. In the event of a state going bankrupt, this is what would allow it to directly debit your bank accounts without your consent. Don’t laugh – this is exactly what happened in [[https://fr.wikipedia.org/wiki/Crise_financière_chypriote_de_2012-2013|Chypre in 2013]].
-Until 2014, banks used the CFONB format (still used for certain transactions). It was a flat, simple, and readable file. But the European authorities, in this case the EPC (European Payment Council), decreed that it was necessary to be more complicated, and created the SEPA format, with XML sauce, then very fashionable. \\ \\
+Reference: [[https://www.cfonb.org/sepa/le-sepa|Comité French Organisation for Banking Standardisation – CFONB]]
-His introduction was particularly chaotic. Poorly designed at the start, the SEPA standard was modified over time, the major absurdities being removed as protests progressed, but its adoption, scheduled for February to 1/2/2014, had to be postponed of 6 months. Our developers remember the hair they lost back then! \\ \\
+</WRAP>
-This standard is not very protective. In fact, anyone who has your account number can include it in a direct debit file, and thus debit your account. Beyond the fraudulent maneuvers of pirates, this is what would happen, for example, in the event of state bankruptcy, as happened in Cyprus: a list of IBANs in SEPA format is enough to immediately drain the corresponding accounts, without their agreement being technically required.
+===== Automatic processing of payments =====
+//**Access:** Accounting -> Export -> Direct Debit Import//
-</bootnote>
+Once you have sent your direct debit file to your bank, the bank carries out the agreed direct debits and notifies you of any rejections, particularly those due to insufficient funds.
+Gestan This feature allows you to automatically process the XML direct debit file you sent to the bank by automatically recording the payment of the corresponding invoices for those direct debits that were not rejected. This saves valuable time when processing large numbers of invoices!
+{{fr:wiki:compta:sepa_04.png?nolink|}}
+Select the **Source file**, the XML file you sent to your bank for payment processing.
+From the drop-down menu, select the**account** to which the direct debit file corresponds.
+The **settlement date** is the date on which the payment was credited to the account.
+The **Load** triggers the upload of the file’s contents.
+In the table, the invoices set up for direct debit and included in the file appear as they do on the statement generated from Gestan
+Remove from the table all payments rejected by the bank, using the **Delete a row** option in the context menu.
+The **Integrate** button will initiate the process:
+  * the status of the corresponding invoice will be set to “Paid”;
+  * a payment entry will be automatically generated, settling the invoice.
+(Thank you, Marie-Astrid, for this idea ;-))
+\\ \\
 -----------------
-{{:wiki:tags:voir_aussi.gif?nolink |}}**Other Accounting articles**
+ℹ️ **Other “Accounting” articles**
+<nspages fr:wiki:compta -nbCol=2 -textPages="" -h1 -r -simpleLineBreak >
-<nspages en:wiki:compta -nbCol=2 -textPages="" -h1 -r -simpleLineBreak >