Copyright Infor. All Rights Reserved.

Transkript

1 1

2 M3 Infoteam 2017 VAT on Import SAF-T SEPA E-banking Terje Fagerås, Infor Norway Lars Bremer, Infor Product development 2

3 AGENDA VAT on Import SAF-T SEPA E-Banking Changes in VAT for import Terje How to manage in M3 - Terje Legal Audit file from 2017/2018 Background Changes in M3 ICS support for SAF-T - Terje New standard for payments in EURO What have we done in M3 Based on MEC ICS support for SEPA projects - Terje What is e-banking in M3 The future will be based on MEC What messages shall we support for Norway Considerations 3

4 VAT on Import Changes in VAT on Import for Norway 4

5 Hovedsaker Fra 1. januar skal selskaper som importerer varer ikke lenger betale ordinær innførselsmva (ikke toll) til tollkassereren men rapportere innførselsmva sammen med øvrig mva på en utvidet moms-rapport Tollkreditt er således ikke lenger nødvendig Omsetningsoppgaven (mva-rapporten) er døpt om til skattemelding for merverdiavgift Krever endring i M3 mva-oppsett og mva-koder. Vil i størst grad påvirke kunder som driver eksport og import Den nye MVA-meldingen er mer oppsplittet og krever økt kunnskap på detaljnivå Særavgifter (toll) rapporteres fortsatt via tollkreditt og Tolletaten 5

6 Endringer i skattemeldingen (MVAoppgaven) Omsetning utenfor MVA-loven har fått egen post Utførsel av varer og tjenester (eksport) skal spesifiseres i egen post Har tidligere vært en del av ordinær fri omsetning Innførsel av varer Utgående innførselsmva (betalbar import-mva) skal nå spesifiseres med både grunnlag og mva i oppgaven og betales sammen med øvrig mva Har tidligere ikke vært med i oppgaven, egen oppgave til Tollkassereren Fradrags berettiget innførselsmva spesifiseres i egen post Har tidligere vært en del av ordinær fradragsberettiget mva Erfaringen med ny konfigurering så langt viser at det er behov for å identifisere ulike omsetningstyper 6

7 Forslag til løsning i M3 Opprette nye/flere mva-koder (CRS030) Utgående og inngående innførsels-merverdiavgift Kode 81 settes opp som reversed charge Innenlands omsetning uten mva Eksport (utførsel uten mva) Omsetning med snudd avregning Ikke aktuelt (gull og klimakvoter) 7

8 Forslag til løsning i M3, forts Nye hovebokskonti for grunnlag utgående og inngående innførselsmerverdiavgift Konto og motkonto Må ha AT04=4 Verdi på tolldeklarasjon debiteres konto for grunnlag innførsel (4xxx) med snudd mva-avregningskode (f.eks kode 81) Medfører både debitering og kreditering av 27xx Motkontèr restverdi på motkonto for grunnlag innførsel (4xx1) med mva kode 0 Sette opp styring av nye mva koder i konteringsreglene i CRS395 Bygge om mva-rapport (TXS005) 8

9 Eldre M3 versjoner (alternativt oppsett) Dersom eldre versjoner ikke støtter reversed charge setter man opp 2 mva-koder for innførselsmva en mva kode for inngående innførselsmva en mva kode for utgående innførselsmva Kontererer innførselsgrunnlaget kredit (istedetfor debet) med mva-kode for utgående innførselsmva Motkonterer innførselsgrunnlaget på dummy motkonto med mva-kode for inngående innførselsmva 9

10 Annet Deklarasjonsoversikten ifølge Skatteetaten: Kommer som rapport i Altinn 2017 En månedlig oversikt over alle tolldeklarasjoner Henter data fra TVINN Se Det utarbeides én oversikt per kundenummer Første tolldeklarasjonsoversikt blir gjort tilgjengelig i 1. el. 2. februar 2017 Toll / særavgifter skal fortsatt betales til Tolletaten 10

11 Spørsmål? Kontakt meg gjerne på: 11

12 SAF-T One common standard for Audit? 12

13 Background From Wikipedia, the free encyclopedia SAF-T (Standard Audit File for Tax) is an international standard for electronic exchange of reliable accounting data from organizations to a national tax authority or external auditors. The standard is defined by the Organisation for Economic Co-operation and Development (OECD). The file requirements are expressed using XML, but the OECD does not impose any particular file format, recommending that (para 6.28) "It is entirely a matter for revenue bodies to develop their policies for implementation of SAF-T, including its representation in XML. However, revenue bodies should consider data formats that permit audit automation today while minimising potential costs to all stakeholders when moving to new global open standards for business and financial data such as XBRL, and XBRL- GL in particular. 13

14 Two versions Versio n v1.0 v2.0 Introduc ed May 2005 April 2010 XML Schema SAF-T.xsd SAF-Tmap.html SAF- T_Schem a_v_2.00. xsd Annotated File Package Content Annotated SAF-T Schema v2.pdf [5] SAF-T v1.0 package General ledger Chart of accounts Invoices Payments Adjustments Enhanced version 1 Inventory Fixed assets 14

15 Country Name Latest XML Schema version Date Based on SAF- T version Portugal SAF-T (PT) 1.03_01 [3] December 2, 2016 SAF-T v1.0 Luxembourg FAIA 2.01 [2] March 13, 2013 SAF-T v2.0 Organization Portuguese Tax Authority / Autoridade Tributária e Aduaneira Luxembourg Tax Administration / Administration de l Enregistrement et des Domaines (AED) Comments Law rule (memo) A-206 of December 24, [6] France FEC? January 1, 2014 N/A French Ministry of Finance FEC FR adopted December 5, 2012 making it obligatory pr. January 1, 2014 for companies to supply file covering years 2011, 2012 and [7][8] However, France's usage of the term "Standard Audit File for Taxation" has been adapted for a file format not based on the OECD SAF-T; their écriture compatible is proprietary. Austria SAF-T AT 1.01 [9] January 31, 2009 SAF-T v1.0 Poland JPK [11] 1.0 July 1, 2016 SAF-T v2.0 Austrian Ministry of Finance / Bundesministerium für Finanzen Polish Ministry of Finance / Ministerstwo Finansów Decree of March 20, 2009 BMF /0002- IV/2/2009. [9][10] The new requirement comes into place on 1 July 2016 for large companies. Small and medium-sized businesses (less than 250 employees) will be required to implement the requirement by 1 July [12] Lithuania SAF-T 1.00 July 1, 2015 [13] SAF-T v1.0 Norway Norwegian SAF-T Financial 1.00 January 1, 2017 [15] SAF-T v2.0 State Tax Inspectorate / Valstybinė mokesčių inspekcija Norwegian Tax Administration / Skatteetaten Article 16 of the Law on Accounting. Resolution No 699 of 1 July 2015 of the Government of the Republic of Lithuania. Order No VA-49 of 21 July 2015 of the Head of the State Tax Inspectorate under the Ministry of Finance. [14] Standard Audit File - Tax (SAF-T) Financial [15] 15

16 SAF-T in Norway Valid for... Sections.. Considerations Businesses with less than NOK 5 million in turnover, or fewer than 600 documents a year, are exempt from this requirement. However, if these businesses do have bookkeeping information electronically available, the requirement will apply to them. a voluntary arrangement up until 1 January General ledger Chart of accounts Chart of accounts defined by Skatteetaten VAT codes defined by Skatteetaten 16

17 SAF-T in Norway Chart of account 17

18 SAF-T in Norway VAT codes 1(2) 18

19 SAF-T in Norway VAT codes 2(2) 19

20 SAF-T in M3 1 Chart of account 2 VAT codes 3 Run AAS3XX Mapp your own chart of account to Skatteetaten in GLS030 Mapp your VAT codes in CRS0XX At period end create your SAF-T files in AAS3XX 20

21 SAF-T COA Translation GLS030 - Account Translation Scenarios GLS031 Scenario Details This is a mandatory translation for Norway that is also available in the standard format as optional information. The translation will therefore be handled as a standard solution triggered by the Scenario ID defined as Additional info. 031 in (TXS035) The user must define the header (for the reporting division using the Scenario defined in TXS035) and the detail lines for the translation. 21

22 SAF-T VAT Code Translation CRS881- Header Auto Creation from AAS300 CRS882 - Detail Option for translation to StandardTaxCode using Business Data Translation. Displ (CRS881/882) The header record is automatically created the first time AAS300 is run). 22

23 AAS300 - Standard Audit File. Create New fields added for SAF-T version 2 with handling of Base country and Language code for Chart of account description. A control is added that opening balance period 00 exist in the balance files if output format = 8 (SAF-T version 2) and Chart of Accounts, Customer master and Supplier master. This is to increase performance during the file creation (The current year s balance is transferred to opening balance for the next year and saved in period 00 when running: 'GL Balance File. Start Annual Run' (GLS905) AR Balance File. Start Annual Run (ARS910) 'AP Balance File. Start Annual Run' (APS910) 23

24 SAF-T Header Record TXS035 Taxation Reporting. Open Report Fields 24

25 SAF-T i Norge Forventes å være frivillig frem til 1. januar 2018 Men Skatteetaten forventer at skattyter leverer på SAF-T format ved bokettersyn dersom ERP systemet har støtte for dette Test og validering Validering av format XSD validator (Skatteetatens eller andre) Innsending av TST-fil til Altinn Ifølge Skatteetaten er det mest utfordringer i grunndata / masterdata Anbefaler derfor å komme igang med en løsning for en validering av masterdata 25

26 SAF-T i Norge Flere faser, i første omgang hovedbok, kunde og leverandører, mva og masterdata 26

27 27

28 SEPA 28

29 What is SEPA? The Single Euro Payments Area (SEPA) is a payment-integration initiative of the European Union for simplification of bank transfers denominated in euro. As of July 2015, SEPA consists of the 28 member states of the European Union, the four member states of the European Free Trade association (Iceland, Liechtenstein, Norway and Switzerland), Monaco and San Marino. 29

30 Three type of messages Supplier payments Direct debiting (Customer Payments) Payment order asking the bank to pay invoices at a certain date Based on a standard Credit transfer SEPA Credit transfer Payment feedback from the bank as Bankstatement Remittance order asking the bank to withdraw cash from customers bank account Based on a standard Debit transfer SEPA Debit transfer Not a part of SEPA...but Based on a standard Bankstatments CAMT053 CAMT054 30

31 Three type of messages/bank in Norge Supplier payments Direct debiting (Customer Payments) DNB SEB NORDEA DANSKE BANK SPAREBANKEN CAMT053 CAMT054 31

32 Erfaringer Implementert for følgende banker DnB, Nordea og Danske Bank Har forøvrig løsning (MEC) for SEB og Sparebankene Ulike erfaringer med ulike banker Test system og CAMT054 Innhold i CAMT054 Nummerering Andre betalinger Norsk løsning benytter ikkepain002 og CAMT053 32

33 Gjennomføring Installasjon av løsning og fixes Konfigurasjon De fleste norske divisjoner velger SEPA for bade innland og utland Gjør Telepay overflødig med mindre det benyttes for innbetalinger Testing Selvbetjent og pr Ikke alle banker leverer CAMT054 for test-format Konverteringsprogram for utenlandske leverandører i norske divisjoner 33

34 Erfaringer utland SE, DK og UK Forholdsvis lik konfigurasjon Benytter allerede MEC for betaling idag Inget konverteringsprogram Beholder dagens betalingsformat for innland og velger SEPA for utland 34

35 E-banking i Norge 35

36 Supplier payments Objective The objective of this process is to send a payment order to the bank for supplier invoices that are almost due for payment. User create payment order File transferred to bank Bank create payments Process The user sends a file with included included invoices after the payment proposal is approved. The structure of the message is a header that identify the sender of the file, next level is information about each receiver of the payments and and the last level is information about each invoice. Solution in M3 User creates the payment proposal in APS130 and sends via APS16X In this process, without feedback, is the assumption that the invoices will be approved by the bank and therefore is the accounting transactions created at the same time as the file is sent. Reconciliation between the account and the bank is done when the bankstatement comes from the bank. 36

37 Supplier payments with feedback Objective The objective of this process is to send a payment order to the bank for supplier invoices that are almost due for payment. The bank will after they have done the payments send one file per payment date with all informations about the payments, such as rates and potential fees One paymentorder with several payment dates User create payment order File transferred to bank Bank create payments One feedback file per payment date Process The user sends a file with included included invoices after the payment proposal is approved. In this process, with feedback, the invoices are not accounted until the feedback file is received. Feedback is used when the invoice is in foreign currency since the rate is unknown until the bank has done the payment. Solution in M3 User creates the payment proposal in APS130 and send vi APS16X. The feedback is managed via ABS100 37

38 Bankremittance Direct debiting Objective Direct debiting is a payment method where the buyer gives the seller the right to withdraw the cash from his account on duedate Process The user sends a remittance file to the bank with invoices that are almost due. The bank connects to the customers bank and withdraw the amount. The bank pays the invoices via the ordinary customer payment process One remittanceorder with several payment dates User create remittance order File transferred to bank Bank create remittance to other bank One feedback file per payment dates Solution in M3 User creates the remittance in ARS300. The feedback is managed via ABS100 38

39 Customer payments Objective The objective of this process is to receive customer payments from the bank in an electronic format Process The bank will create a file that is sent on a regular basis to the customer. The information can either be a total for several invoices or there is one amount per payment. The information from the file is converted and downloaded into M3. M3 performs the allocation of the amount to the right invoice via various algorithoms. If not possible, the user has to manually take care of the not allocated payments. This is used for ordinary payments, payments from direct debiting, creditcard payments and other customer payments. User manage not allocated payments File transferred from bank Solution in M3 The payment file is managed via ABS100 Bank create payments 39

40 Bank statements Objective The objective of this process is reconcile the transaction on a bankaccount between the banks transactions and the transaction in the General ledgar for that bankaccount User manually adjust not reconciled transactions File transferred from bank Bank create payments Process The bank will create a file that is sent on a regular basis to the customer. The file is converted and updated in to M3. A function start the reconciliation between the transactions from the bank to the transactions in the Geberal ledger. Matching transactions are reconciled and others are flagged as being subjects for manual investigations. Solution in M3 The statement is managed via GLS180 40

41 Requested formats? Supplier Payment order SEPA DNB SEB NORDEA DANSKE BANK SPAREBANKEN Other formats? Supplier payment feedback CAMT.054 Other formats? Direct debiting Customer Payments Bank Statements? CAMT.053 CAMT.054 Other formats? `? 41

42 42