C est bien évidemment ce qui est demandé. Un fichier par agent payeur (KBC,

N Questions/Remarques ° 1 Hoeveel files moeten we aanmaken ? - 1 per paying agent (dus 1 KBC, 1 CBC en 1 Centea) ? 2 Wat invullen in Message ID : volgens richtlijn moet dit uniek zijn over “space and time” 1 deel is landcode van de afzender, dus vermoedelijk BE Ander deel is een identifier. Wat moeten we hier invullen ? En is het de bedoeling om bij een correctie of aanvulling dan ook de vorige Message ID in te vullen ? 3 Moeten we antwoord op vraag correcties automatiseren ? En zo ja, hoe zit het met weigering van deze aanvragen ? 4

Structuur DOCrefID Welke aanduiding voor Residuele entiteit gebruiken : RE ?

Réponses C’est bien évidemment ce qui est demandé. Un fichier par agent payeur (KBC, CBC,…) Cfr. point II.2 du protocole JMonnet. Le MessageID est unique dans le temps et dans l’espace. Par conséquent, on ne peut le réutiliser dans aucun message ultérieur même en cas de correction spontanée. Dans ce cas précis, il y a lieu de générer un nouveau MessageID tout en reprenant dans CorDocRefID l’identifiant du record initial à corriger.

Actuellement les demandes de correction ne sont pas traitées de façon automatique. Elles seront traitées manuellement au cas par cas en utilisant notamment, la liste des personnes de contact par institution financière (agent payeur) fournie par FEBELFIN au SPF FINANCES. Cas : code Agent Payeur : PA

Identifiant [BE][XXXXXXXXXX][-PA-] [YYYY]-[NNNNNN]

Long 27

Exemple BE0403201185-PA2011-000001

Bénéficiaire effectif : BO Entité résiduelle : RE Paiement : Art9

[BE][XXXXXXXXXX][-BO-] [YYYY]-[NNNNNN] [BE][XXXXXXXXXX][-RE-] [YYYY]-[NNNNNN] [BE][XXXXXXXXXX][-ART9-] [YYYY]-[NNNNNN] [BE][XXXXXXXXXX][-ART4.2-] [YYYY]-[NNNNNN]

27

BE0403201185-BO2012-000001 BE0403201185-RE2013-000001 BE0403201185-ART92015-000001 BE0403201185ART4.2-2016-000001

Paiement Art4.2

:

27 29 31

o [XXXXXXXXXX] correspond au numéro BCE (Banque Carrefour des Entreprises) de l’agent Date impression : 17/12/2010 Statut : Approuvé

Page 1 sur 25 Contact : [email protected]

DateVersion : 20122010v3

payeur, o YYYY : année en cours, NNNNNN : indicateur numérique composé de 6 chiffres de séquence, réinitialisé chaque année. 5

Wat zijn de gevolgen als een cliënt 2 maal gerapporteerd wordt (dubbele cliëntnummers) ?

Date impression : 17/12/2010 Statut : Approuvé



6 7

Is 7 jaar corrigeren een verplichting ? (of wordt dit overgelaten aan de banken zelf ?) Wat bedoelt men met “4. En ce qui concerne les champs obligatoires tels que définis par la Commission de l’UE,

Selon l’XSD ci-dessus, il est tout à fait possible de renseigner un seul client avec autant de paiements que nécessaire. Par ailleurs, le même client peut être référencé, également, différemment au sein de la même banque. La durée de 7 ans est basée sur la législation belge en la matière. Selon l’XSD FISC 153 certains champs sont obligatoires est donc il faut fournir les données auxquels ils se rapportent. D’autres champs sont optionnels




8

9

ceux-ci doivent être respectés. Les champs optionnels pour lesquels il …document restent en toute hypothèse optionnelle. Le cas échéant une mention ‘unknown’ ou une autre mention par défaut (exemple : x) doit être mentionnée ». MessageTypeIndic - waarde 3 (cancellation) fisc 153 : pg. 18 : gereserveerd voor toekomstig gebruik protocole_Jmonnet : pg. 5 : zal wel gebruikt kunnen worden. Betekent dit dat het annulatieproces intussen wel verder uitgewerkt is en dat we ons op protocole_jmonnet mogen baseren : dus mogelijkheid om waarde 3 wel in te vullen en te gebruiken ? Zal in geval van vragen van de buitenlandse fiscus een refertenummer van de fiscus zelf (buitenlandse of Belgische) meegegeven worden ?

est par conséquent, l’institution financière n’est pas obligée de les fournir sauf pour améliorer la qualité des données transmises.

L’actuelle version du protocole ne préconise plus le chiffre 5 pour les tests. Cette option est offerte par un environnement de tests indépendant de celui de la production. Par ailleurs, il est effectivement possible d’utiliser le code 3 pour annulation.

A ce jour rien n’est prévu pour les demandes d’informations complémentaires pour les identifier moyennant une référence unique. Ceci devrait faire partie d’une procédure annexe manuelle qui ne fait pas partie de cette phase du projet.

Indien wel : Stel dat we deze referte intern zouden willen opslaan ifv opzoekingen, hoe zal deze referte eruit zien ? We zouden dit dan evt. in onze database al kunnen voorzien en toekomstige aanpassingen vermijden in ons datamodel. 1 0

In de documenten Jmonnet die in februari verspreid zijn, is er sprake van testaanleveringen. Hiervoor moeten we MessageTypeindic op 5 zetten.

Nous avons séparé les écrans de test de ceux de production. Par conséquent, il n’est plus nécessaire d’indiquer le chiffre 5 pour “test”. Il faut indiquer le bon chiffre selon vos scénarios de test (nouveaux cas, annulation, les deux à la fois).

De printscreens voor de upload hebben 2 knoppen : Date impression : 17/12/2010 Statut : Approuvé



enerzijds opsturen - anderzijds opsturen als test Hoe moeten we dit interpreteren ? - Moet een file met MessageTypeIndic op 5 steeds afgestaan worden via de testknop ? of - Kan je die file ook via de gewone knop afstaan waarbij dan door de waarde van MessageTypeIndic die file als testfile verwerkt zal worden ? Omgekeerd : - Mogen we een file met een MessageTypeIndic verschillend van 5 ook afstaan via de testknop ? En zal deze file dan zeker als test behandeld worden ? 1 1

De printscreens uit de documenten Jmonnet van februari printscreens zullen de waarde voor "nombre d'enregistrements" teruggeven.

Effectivement, il s’agit du nombre total des paiements (PaymentData) repris dans le fichier. Attention, il n’y a qu’un seul “Paying Agent = banque” par fichier.

Slaat dit op het aantal PaymentData's die in de XML file zitten ? Dus het totaal aantal keer dat een PaymentData gerapporteerd wordt over de hele file heen (dus voor verschillende artikels (4.2/9) en verschillende paying agents en beneficial owners) ? 1 2

Het LegalAdressType is een optioneel veld voor een residuele entiteit. Welk is het legaladresstype voor een residuele enititeit ?

Cfr. Fisc79 (5.2.2.4) : The legalAddressType_Type is used to describe the legal character of an address. It is based on the legalAddressType_Type of the STF:




<xsd:simpleType name="legalAddressType_Type"> <xsd:restriction base="xsd:token"> <xsd:enumeration value="residentialOrBusiness"/> <xsd:enumeration value="residential"/> <xsd:enumeration value="business"/> <xsd:enumeration value="registeredOffice"/> <xsd:enumeration value="unspecified"/>

XML Fragment 1: legalAddressType_Type (STF) For the purposes of the Savings Directive, “fiscalResidence” is added: <xsd:simpleType name="legalAddressType_Type"> <xsd:union memberTypes="stf:legalAddressType_Type"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:pattern value="fiscalResidence"/>

XML Fragment 2: legalAddressType_Type (SDF) Value residentialOrBusiness residential business registeredOffice unspecified fiscalResidence

Description The address is either a residential or business address The address is residential The address is business The address is the registered office of the legal person The nature of the address is not specified The address is for fiscal purposes (this is relevant for Beneficial Owner only)

Table 1: Allowed values of the legalAddress_Type Date impression : 17/12/2010 Statut : Approuvé



5.2.2.5. Address_Type The Address_Type allows either a structured address (AddressStruct) or a free format address (AddressFree). The CountryCode of the address is provided separately from these types and is mandatory. Whenever possible, the AddressStruct element must be supplied, even if only partial details from the address can be matched to an element (for example a postal code or city). The AddressFree can be used to supplement an incomplete AddressStruct. The optional legalAddressType attribute allows the type of address to be provided, from among the values in Table 1, if this is known.

Figure 1: Address_Type




<xsd:complexType name="Address_Type"> <xsd:sequence> <xsd:element name="CountryCode" type="dt:CountryCode_Type"/> <xsd:choice> <xsd:element name="AddressFree" type="xsd:string"/> <xsd:sequence> <xsd:element name="AddressStruct" type="sd:AddressStruct_Type"/> <xsd:element name="AddressFree" type="xsd:string" minOccurs="0"/> <xsd:attribute name="legalAddressType" type="sd:legalAddressType_Type" use="optional"/>

XML Fragment 3: Address_Type 1 3

Structuur DOCrefID : Welke aanduiding voor Residuele entiteit gebruiken : RE ?

Cas : code Agent Payeur : PA

Identifiant [BE][XXXXXXXXXX][-PA-] [YYYY]-[NNNNNN]

Long 27

Exemple BE0403201185-PA2011-000001

Bénéficiaire effectif : BO Entité résiduelle : RE Paiement : Art9

[BE][XXXXXXXXXX][-BO-] [YYYY]-[NNNNNN] [BE][XXXXXXXXXX][-RE-] [YYYY]-[NNNNNN] [BE][XXXXXXXXXX][-ART9-] [YYYY]-[NNNNNN] [BE][XXXXXXXXXX][-ART4.2-] [YYYY]-[NNNNNN]

27

BE0403201185-BO2012-000001 BE0403201185-RE2013-000001 BE0403201185-ART92015-000001 BE0403201185ART4.2-2016-000001

Paiement Art4.2

:

27 29 31

o [XXXXXXXXXX] correspond au numéro BCE (Banque Carrefour des Entreprises) de l’agent payeur, o YYYY : année en cours, NNNNNN : indicateur numérique composé de 6 chiffres de séquence, Date impression : 17/12/2010 Statut : Approuvé



réinitialisé chaque année, 1 4

Cfr. JMonnet februari pg. 2 Ligt er al een limiet vast wat betreft grootte orde bestand ?

1 5

1 6

Is al geweten of file in ZIP formaat moet afgestaan worden ? Wat bedoelen ze met "4. En ce qui concerne les champs obligatoires tels que définis par la Commission de l’UE, ceux-ci doivent être impérativement respectés. Les champs optionnels pour lesquels il n’est pas dérogé dans le présent document restent en toute hypothèse optionnelle. Le cas échéant une mention ‘unknown’ ou une autre mention par défaut (exemple : x) doit être mentionnée"

We moeten rekening houden met een mogelijke versiewissel van het XSD-schema. Mogen we van de veronderstelling uitgaan dat een versiewissel steeds gekoppeld zal zijn aan een inkomstenjaar ? Ik bedoel daarmee dat als een wisseling van versie zal gebeuren, moeten we dan bv de XML van de vorige inkomstenjaren met de vorige versie en van de komende

Cette information sera donnée après les premiers tests avec MyminfinPro. Les fichiers sont automatiquement compressés lors du transfert donc il n’y a pas lieu de le faire avant.

Velden worden als verplicht of optioneel aangeduid in de XML-schema’s. De tabellen in fisc 80 (pg 118 – 125) geven naast de indicatie verplicht/optioneel ook aan of een lege waarde toegelaten is of niet. Geeft dit problemen indien toch een blanco waarde afgestaan wordt ? veld optioneel en lege waarde indicator in fisc 80 staat op N : dan mag dit veld dus niet afgestaan worden ? Nous disons bien : “…Les champs optionnels pour lesquels il n’est pas dérogé dans le présent document restent en toute hypothèse optionnelle. Le cas échéant le mot ‘unknown’ doit être mentionnée" Cette matière ne dépend pas du SPF FINANCES, ceci relève des compétences de la Commission Européenne et du groupe de travail ACDT. A priori, en cas de nouvelle version, ces deux organismes préciseront la démarche à suivre.




1 7

inkomstenjaren met de nieuwe versie maken ? MessageTypeIndic in de header - Volgens JMOONET wordt de waarde 4 (nieuw en correcties) niet langer gebruikt - Maar als je dan een spontane correctie doet (vb 30/6) - de gewijzigde gegevens krijgen in de DocTypeIndic de waarde "2" van wijziging - de nieuwe gegevens zouden dan in de DocTypeIndic de waarde "1" van nieuw krijgen - Maar als je dan de regels rond MessageTypeIndic en DocTypeIndic gaat nalezen mag je dus blijkbaar MessageTypeIndic "2" niet combineren met een DocTypeIndic "1"

La nouvelle version du protocole permet d’utiliser le MessageTypeIndic de valeur = 4 pour pouvoir mettre dans le même fichier FISC 153 des informations nouvelles et des annulations.

Moeten we dan in dit geval 2 XML-rapporteringen gaan aanmaken, 1 voor de nieuwe gegevens en 1 voor de gewijzigde gegevens ? Zou nog logisch zijn als je een volledig nieuwe BO hebt maar als je als een BO doorgestuurd hebt en daar nog payments aan moet toevoegen ga je eigenlijk in nog eens diezelfde BO moeten doorsturen ? 1 8

1ère situation

1ère situation :

En 2010, le client a reçu 10.000 EUR d’intérêts sur son compte à terme. La banque ne déclare pas (pour quelque que raison que ce soit) ce « paiement d’intérêts » dans le reporting 2011

La banque doit communiquer cette information en tant que nouvelle déclaration avec un numéro de référence unique tout en précisant dans le champ ad hoc l’année du paiement (cfr. FISC 80).




(relatif aux « paiements d’intérêts » attribués en 2010). Comment doit-elle procéder pour communiquer par après cette information ?

2éme situation : Idem situation 1. Réponse à la question générale :

1er possibilité : dans un reporting suivant (relatif aux

« paiements d’intérêts » de l’année au cours de laquelle l’absence de déclaration est constatée, comme s’il s’agissait d’un « paiement d’intérêts » fait ou attribué au cours de cette année là).

La banque doit corriger ou annuler l’opération du passé en effectuant une déclaration individuelle limitée au « paiement d’intérêts » à corriger ou à annuler. Cette correction peut être faite au sein d’un fichier contenant de nouvelles déclarations.

2ème possibilité : au moyen d’une déclaration corrective (du

reporting 2011) mais dans ce cas, sans pouvoir mentionner un « numéro de référence unique » puisqu’il n’y a pas eu de communication initiale d’informations. 2ème situation En 2010, le client n’a reçu aucun « paiement d’intérêts ». Rien n’est déclaré dans le reporting 2011 (relatif aux « paiements d’intérêts » attribués en 2010). Plus tard, la banque se rend compte d’une erreur (quelque soit la raison de cette erreur) : le client avait droit, en 2010, à un intérêt de 500 EUR. Comment doit-elle procéder pour communiquer cette information ? 1er possibilité : dans un reporting suivant (relatif aux Date impression : 17/12/2010 Statut : Approuvé



« paiements d’intérêts » de l’année au cours de laquelle le « paiement d’intérêts » est finalement fait ou attribué). 2ème possibilité : au moyen d’une déclaration corrective (du

reporting 2011) mais dans ce cas, sans pouvoir mentionner un « numéro de référence unique » puisqu’il n’y a pas eu de communication initiale d’informations. Question générale Dans l’hypothèse d’une correction ou d’une annulation d’un « paiement d’intérêts » déclaré dans un reporting précédent, la banque doit-elle corriger ou annuler l’opération du passé en effectuant une déclaration individuelle (reporting) limitée au « paiement d’intérêts » à corriger ou à annuler ? OU peut-elle envoyer un tout nouveau reporting complet pour l’année concernée (sorte de mise à jour d’une version précédente qui remplace cette version précédente) et dans ce cas, combien de fois par an ?

1 9

Les critères de cumul : Question : Allez-vous garder au niveau belge l'Art9PaymentData comme défini dans le document FISC 135 ? Partant de cette hypothèse, peut-on en déduire que le regroupement se fera par les palliers suivants : 1) Par BO / Pays de résidence ; 2) Par SpecificPaymentType ;

Le SPF FINANCES fait uniquement le dispatching vers les pays destinataires et rien d’autres. Ce dispatching se base sur le code pays de résidence du bénéficiaire.




2 0

2 1

3) Par Devise; 4) Par compte. Si cette hypothèse est retenue, comment définir un DocRefId pour l'article 9 de paiement ? Si je garde le schéma actuel de l'art9 de paiement, cela voudrait-il dire que si j'ai dans un même type de paiement deux devises, j'aurai un même DocRefId pour les deux paiements ? Ou alors si j'ai deux comptes qui ont reçu les paiments, ces deux comptes auront le même DocRefID ? Autre point d'interrogation : à la page 7 de la V3 du document 'Protocole JMONNET' , vous définissez la structure du DocRefID pour le PA, le BO, l'Art9 de paiement et l'Art4.2 de paiemnet. Nulle part je ne trouve la définition de cette structure pour une Entité Résiduelle. Est-ce à dire que celle-ci n'a pas besoin d'avoir une référence unique ? Een klant van de financiële instelling in België woont gedurende 6 maand in Frankrijk en heeft daar ook zijn fiscale residentie maar verhuist in juli naar België en behoudt zijn fiscale residentie in Frankrijk. De intresten worden toegekend per einde jaar dus op het moment dat zijn woonplaats in België is maar zijn fiscale residentie nog steeds in Frankrijk.

Cfr. Question 13 de ce document.

L’adresse à indiquer dans l’XML est toujours l’adresse de la résidence fiscale.

We moeten dus informatie uitwisseling doen maar onze vraag is welke adres we moeten opgeven in de XML file. Het adres op moment van betaling van intresten, zijnde het Date impression : 17/12/2010 Statut : Approuvé



adres in België of zijn oorspronkelijk adres in Frankrijk?

2 2

betreft de reporting van “intrestbetalingen” waarvan de Uiteindelijk Gerechtigde (UG) een gelijkgesteld niet-inwoner is. Voorbeeld : De heer Dupont

is een Europese ambtenaar met een wettelijk adres in Brussel en een fiscale woonplaats in Frankrijk (zoals vermeld op attest HIS 276) Hij heeft een termijnrekening bij een Belgische bank die 1.000 EUR in de loop van 2010 opbrengt. Hoe zal de Belgische bank doen om die situatie te rapporteren ?

Cfr. Réponse 21. Pratiquement dans ce cas, ResCountryCode= Fr puisque c’est le pays de la résidence fiscale comme declaré dans le document HIS 276.

Voorstel : Op

het document FISC153 (bladzijde 41) staat de structuur vermeld voor wat betreft The Beneficial Owner. Er zijn twee vaken : ResCountryCode en Address – CountryCode. Zou de Belgische bank het vak ResCountryCode kunnen gebruiken om de Tax Country van de UG te communiceren ? Op basis daarvan zou de Belgische fiscus weten naar welke EU lidstaat deze info moet worden doorgestuurd ? Is dat (praktisch gezien) aanvaardbaar ?

2 3

Voor Residuele Entiteiten (Art.4_2) dienen we cfr. jullie informatie in vrije text de naam van de gerechtigde (the of the Beneficial Owner ) mee te delen.

name

Cfr. Protocole. Le nom de l’entité résiduelle ne peut qu’être « free ».

BASE:




/dt:DirectTaxMessage/dt:Body/sd:InitialElements/sd:Article4_2 LOCATION: sd:Entity/NameFree

Figure 10 - Name of the Entity The NameFree element allows entering the name of the entity as free text. It has an optional attribute, nameType, which can take one of the following values, inherited from STF:




Maar in het xsd-schema is (NameFree) een groepsveld en geen element dat een waarde kan bevatten ??? <xsd:complexType name="EntityParty_Type"> <xsd:sequence> <xsd:element name="OtherInfo" type="sd:OtherInfo_Type"/> <xsd:element name="NameFree" type="sd:EntityName_Type"/> <xsd:element name="Address" type="sd:Address_Type"/> <xsd:attribute name="oecdLegalType" type="stf:oecdLegalType_Type" use="required" fixed="06"/>

Kunnen jullie ons hiermee verder helpen aub. ? Date impression : 17/12/2010 Statut : Approuvé



2 4

Vraag rond de paying agent bij splitsen files :

C’est l’option 1. File 1 : - Header 1– body 1(PA1 + BO1) File 2 : - Header 2– body 2(PA1 + BO2)

Wanneer we een file moeten splitsen owv volumes hoe moeten we dan de files aanmaken optie 1 1e file : initial elements (met een paying agent) 2e file : initial elements met een nieuwe paying agent (dus nieuwe docreferte maar met dezelfde gegevens als die van file 1) optie 2 1e file : initial elements (met een paying agent) 2e file : spontane correcties voor paying agent met nieuwe beneficial owners en paying agents

2 5

Based on the documentation available on the febelfin extranet, we are building a solution

1. acctNoQlf : It’s a free text zone so you should indicate the real type of the account number.




to generate the XML DirectMessageTag. After a detailed analysis of the available specifications, we still have a few questions. We would appreciate if you could take the time to answer them or to forward this message to the appropriate persons.

2. secNoQlf : It’s a free text zone so you should indicate the real type of the security number. 3. othQlf : It’s a free text zone wich allow you to indicate more specific personal.

1) What is the list of possible values for the attribute acctNoQlf of the OBAN element? Or is a it free text we can fill as we like? The account structure we use at Petercam is 15-2 which is neither an IBAN nor a BBAN number. We therefore have to use the OBAN element. This element has a *compulsory* acctNoQlf allowing to indicate which type of account is used. In the sample xml file downloaded from the febelfin extranet, we noted that this attribute was always set to "BBAN". --> So, as our account structure is not a BBAN, what value should we use to fill in the attribute acctNoQlf? 2) What is the list of possible values for the attribute secNoQlf of the OSIN element? Or is a it free text we can fill as we like? 3) What is the list of possible values for the attribute othQlf of the OtherPersData element? Or is a it free text we can fill as we like?




2 6

Worden volgende wijzigingen effectief van kracht vanaf 01/01/2011: 1) afschaffing grootvaderclausule: In FAQ van Febelfin op p. 14 staat ivm grootvaderclausule: 'In principe is de clausule van toepassing tot 31 december 2010.' Waarom staat er 'in principe' ? 2) wijziging van drempel van 40% naar 25% bij verkoop of terugbetaling op vervaldag van beveks:

Momenteel is de verkoop of terugbetaling op vervaldag van beveks die minder dan 40% beleggen in rentedragende producten niet onderworpen aan Europese spaarfiscaliteit. Wijzigt 40% naar 25% vanaf 01/01/2011 ? 2 7

1) In verband met het TIN-nummer heeft de fiscus een document uitgewerkt waarin voorbeelden van ID-kaarten van verschillende betrokken landen vermeld staan en waarin uitgelegd wordt waar men het TIN-nummer op de betreffende ID-kaart kan terugvinden. Men zou het document in principe moeten terugvinden op Fisconet door op een link in bijlage n°6 van de circulaire Ci.R.9.Div./602/285 (AOIF nr 25/2010) dd 12.03.2010 te klikken maar deze link werkt niet. Zou u ons het document kunnen bezorgen? 2) Waarom moeten we niet-residenten identificeren vai het TIN-nummer? Mag dit niet

1. La clause de grand-père s’achève bien le 31/12/2010 pour les agents payeurs belges. L’expression « en principe » n’est plus pertinente. Le fait que la Belgique ait basculé dans le système d’échange d’informations a pour conséquence que la clause de grand-père ne peut pas être prolongé en Belgique au delà du 31/12/2010.

2. A compter du 1/1/2011, le seuil de 40% passe bien à 25%. Pour les cessions/ remboursements/rachats de parts d’OPCVM faits à partir de cette date, il convient donc d’appliquer le seuil de 25% pour déterminer si le paiement tombe dans le champ d’application de la directive et, si oui, effectuer l’échange d’informations. 1. En ce qui concerne le lien pour les Numéros d'Identification Fiscal (NIF), le bon lien est bien : http://fngsvvmefiscd01/interfaoiffr/Werkgevers/Fichesopgaven/nif.htm Vous pouvez également accéder à cette page de la manière suivante : sur le site www.minfin.fgov.be, choisir "Administrations" --> "Impôts et Recouvrement" --> "Fiscalité des entreprises et des revenus" ou sur www.fiscus.fgov.be. Sur ce site, sous la rubrique "Avis aux employeurs et débiteurs de revenus" choisir "fiches et relevés (Fr, De, Nl) puis sur le lien NUMERO D'IDENTIFICATION FISCALE (NIF)

2. A partir du moment où l’information est disponible, ce TIN est




gewoon via naam, voornaam, geboortedatum, geboorteplaats, ...?

2 8

impérativement à mentionner en plus.

3) Op basis van welke criteria moeten interesttransacties gegroepeerd worden vooraleer ze worden doorgestuurd naar Minfin. zelfde persoon, type contract, munt, fiscale woonplaats, ... Verschillende uitkeringen van intresten op eenzelfde product mogen geglobaliseerd worden in de rapportering – is het ook toegestaan om verschillende uitkeringen van intresten in detail te rapporteren? Voorbeeld: termijnrekening met plaatsing 1 van januari 2010 tem juni 2010 plaatsing 2 van juli 2010 tem december 2010

3. Il faut regrouper par Personne, Type de contrat, Type de compte, Devise et adresse fiscale

Les agents payeurs belges peuvent, bien entendu, effectuer deux fournitures d’informations lorsque plusieurs payements d’intérêts sont globalisés sur un même produit. Dans l’exemple ci-contre, les agents payeurs belges devraient pouvoir effectuer 2 échanges d’informations. Cela peut s’avérer utile pour l’Etat membre qui reçoit l’information. En effet, entre les 2 échéances (juin et décembre 2010), le revenu pourrait être rattaché à 2 exercices fiscaux différents, le bénéficiaire effectif pourrait avoir changé d’Etat membre de résidence ou même le bénéficiaire effectif pourrait ne plus être la même personne.

hebben we de keuze in de gegevensuitwisseling om plaatsing 1 en 2 apart te rapporteren of te globaliseren?

2 9

Vraag 1: Bij opmaken van een record zijn er verschillende elementen die mogelijk als uniek kunnen beschouwd worden. Men kan uniek werken op naam, rekeningnummer met als bijkomende onderverdeling per type betaling of munt. Welk is de structuur of volgorde (key) die dient gerespecteerd te worden?

1. Pour un même produit, les différents paiements d'intérêts peuvent en effet être globalisés. Par contre, les paiements d'intérêts d'une même catégorie mais correspondant à plusieurs produits différents (exemple : plusieurs comptes bancaires distincts) ne devraient pas être globalisé. 2. La circulaire peut être consultée via le portail des Finances (Fisconet plus)




Mag men bij aangifte voor fysieke personen (article 9) iedere betaling als een aparte record beschouwen? Of dient men totalen te maken per PayementType? Vraag 2: Tijdens de infosessie van 16 september heeft Dexia hun project toegelicht. Ook hebben zij gemeld welke informatie er ter beschikking is. Een van de belangrijke was: Administratif circular dd 12/03/2010. Zou u ons kunnen melden waar wij deze kunnen bekomen? Vraag 3: Bank X is een Commanditaire Vennootschap op Aandelen dient men dan als oecdLegalType “03” gebruiken (Partnership)? Vraag 4: In MonAmnt dient men het “gross amout” ingeven m.a.w. het bruto bedrag. Indien er echter 15% Roerende Voorheffing is afgehouden dient men dan het netto of bruto vermelden? Vb: In een onverdeeldheid van 4 zit een begunstigde die in een ander europees land vertoeft. Er wordt 100 euro brut uitbetaald maar min 15% roerende voorheffing. Zal men dan 25 euro (brut) aangeven voor deze persoon of 21 euro (net)? Vraag 5: Bij uitbetaling van een buitenlandse obligatie waar reeds buitenlandse taks afgehouden werd door de uitbetalende buitenlandse instantie (of correspondent) dient men dan bij uitbetaling aan een klant aangifte te doen van bruto? Of

3. Nous ne comprenons pas la question puisque « oecdLegalType” concerne uniquement le BOParty_Type. Ne s’agit-il pas plutôt de “PALegal_Type” où il faut mettre 6 comme valeur ?

4. Il faut renseigner 25 euro (brut).

5. Lorsque des revenus d'origine étrangère sont payés en Belgique et qu'un impôt étranger a été retenu sur ces revenus, il y a lieu de déduire cet impôt étranger du montant à communiquer. 6. Il convient de rapporter dans la devise des intérêts perçus.

7. Il convient de distinguer le dernier coupon, qui correspond ici au paiement d’un intérêt entre 2 échéances (PayementType A), de l’élément « plus-value » (PayementType B). Pour ce dernier, la directive donne le choix aux Etats membres entre la communication soit du montant total du remboursement soit de la plus-value (différence entre remboursement et valeur initiale : 3.000 euro dans l’exemple ci-contre). 8. Il est clair que les agents payeurs belges ne sont pas obligés de considérer un décès comme un paiement d'intérêt au sens de la directive épargne. 9. PaymentQlf doit toujours = “gip”




van bruto min buitenlandse taks? Vraag 6: Bij een obligatie in vreemde munt die wordt uitbetaald in vreemde munt diet men het bedrag in vreemde munt aan te geven met vermelding van devies. Maar voor een obligatie in vreemde munt, die rente betaald in vreemde munt, en voor de klant wordt omgezet naar een betaling op zijn euro rekening dient men dan het rente bedrag in euro of in devies aan te geven?

10. Il faut prendre en considération la date de début de la relation contractuelle.

Vraag 7: Indien men spreekt over een terugbetaling van een obligatie. Heeft men enerzijds de laatste obligatiecoupon die betaald (PayementType A) en anderzijds heeft men mogelijk een premie indien de inschrijvingsprijs kleiner was dan de terugbetaling. Dient men dan het percentueel verschil aan te geven (PayementType B)? En is dit wat men bedoelt bij een “Totaal bedrag van de opbrengst van de overdracht” bij een PaymentType B? Vb: Een klant, buitenlander, schrijft in voor obligatie 100.000 nominaal aan 97% en terugbetaling aan 100%. Dient men dan de 3000 euro aan te geven als PayementType B? Vraag 8: Wat dient er te gebeuren bij een nalatenschap? Tijdens een periode heeft men een rekening met titularisen die na afwerking van de successierechten over een deel van de Date impression : 17/12/2010 Statut : Approuvé



erfenis zullen beschikken. Mogelijk is er een der erfgenamen onderhevig aan woornstaatheffing. Heeft de datum van overlijden enige invloed in deze veronderstelling? Vraag 9: Bij paymentQlf_Type spreekt men over gip, nip, twth en trt. Bestaat er ergens een duidelijke omschrijving wat er bedoelt wordt met deze termen? Of bestaat er ergens een voorbeeld van deze bepalingen? (misschien komt daar meer duidelijkheid over op 7 oktober) Vraag10: Als men spreekt over datum opening van een rekening. Doelt men dan echt over de datum opening rekening of, in sommige gevallen, over de datum wanneer de eigenaar mogelijk verhuist naar het buitenland en van dan af onderhevig is aan woonstaatheffing? Of moment dat een buitenlander titularis wordt van een reeds bestaande rekening? 3 0 3 1

Als er een interestbetaling is in USD op een rekening in EURO, in welke munt moet de interest gerapporteerd worden: USD of EURO? Dear, Two question regarding the reporting on addresses: 1. Can we report about foreign addresses as follows? Using the City tag to report the City and the Post code and leaving the PostCode tag empty?

Il convient de rapporter dans la devise des intérêts perçus donc en USD dans ce cas-ci. 1. Non, il faut impérativement utiliser PostCode pour renseigner « 40006 » dans votre cas : < AddressStruct> < Street > VIA CARINA <BuildingIdentifier>75 < PostCode >40006< /PostCode > BOLOGNE < /AddressStruct>




urn:AddressStruct> stf:Street>VIA CARINA 75 stf:PostCode> stf:City>I-40006 BOLOGNE urn:AddressStruct>

2. L’approche est correcte.

2. If we have the following case: De heer Dupont is een Europese ambtenaar met een wettelijk adres in Brussel en een fiscale woonplaats in Frankrijk (zoals vermeld op attest HIS 276) Hij heeft een termijnrekening bij een Belgische bank die 1.000 EUR in de loop van 2010 opbrengt. Can you confirm the approach below? We will use the ResCountryCode Tag to report about his Tax Country FR, and use the Address Tag to report about his legal address? urn:BeneficialOwner oecdLegalType="01" contractBefore2004="true"> FR M 1935-10-08 François Dupont Date impression : 17/12/2010 Statut : Approuvé



BE <stf:Street>EZELSSTRAAT 6 <stf:PostCode>1000 <stf:City>BRUSSEL 1 BE0403201185-BO-2010000339

3 2

Quel est la procédure actuelle à suivre pour les corrections spontanées ?

En attendant l’implémentation des corrections spontanées de type 2 par le SPF FINANCES en 2012, il y a lieu de procéder de la sorte : 1. Envoyer une annulation du BO concerné en indiquant son DocRefId et un DocTypeIndic = 3, 2. Envoyer un nouveau fichier contenant les nouvelles données du BO annulé avec un nouveau DocRefId et un DocTypeIndic = 1,

3 3 3 4 3 5




C est bien évidemment ce qui est demandé. Un fichier par agent payeur (KBC,

Recommend Documents