ERP system og programvareutvikling for e-faktura i Türkiye

For å drive virksomhet i Türkiye må et ERP system vanligvis støtte e-Fatura og e-Arşiv – og e-İrsaliye i enkelte sektorer – gjennom skatteforvaltningen (GİB), normalt via en privat integrator. ERP-systemet oppretter dokumentet i UBL-TR-format, selgeren signerer det med det finansielle seglet (mali mühür), integratoren klarerer det hos GİB, og den avgiftspliktige er fortsatt ansvarlig for oppbevaringen hele veien. God programvareutvikling må derfor dekke både dataflyt og etterlevelse.

Hva må et ERP system støtte for å drive virksomhet i Türkiye?

Türkiye bruker elektronisk fakturering som et klareringssystem: Selgeren oppretter et dokument, sender det gjennom en autorisert kanal, skatteforvaltningen validerer det, og først da får det juridisk virkning. For en virksomhet som driver driften sin i et ERP system, får dette konsekvenser på fire steder i systemet:

Dokumentopprettelse. ERP-systemet – eller en tilkoblet motor – må generere fakturaer i den påkrevde UBL-TR-strukturen, med kodene, partsidentifikatorene og dataene på linjenivå som skjemaet krever, ikke et utskrevet oppsett som er omformet til XML.

Digital signering. Dokumentene signeres med det finansielle seglet som er utstedt til den avgiftspliktige. Signeringen må inngå i flyten, med nøkkelhåndtering som samsvarer med ordningen for oppbevaring av seglet.

Toveisutveksling. I e-Fatura-regimet avgjør motpartens registreringsstatus dokumenttypen, og innkommende dokumenter – mottatte fakturaer, svar og kanselleringer der dette er tillatt – må tilbakeføres til ERP-systemet med sine opprinnelige identifikatorer. Ellers mister regnskapet koblingen mellom systemet og det offisielle dokumentet.

Arkivering og gjenfinning. Utstedte og mottatte dokumenter må kunne hentes frem i den lovpålagte oppbevaringsperioden. Om integratoren lagrer dem, ERP-systemet lagrer dem, eller begge gjør det, må avgjøres før produksjonssetting og ikke etter en forespørsel fra revisor.

De fleste virksomheter løser ikke dette ved å bygge om ERP-systemet, men ved å koble det til en integrasjon: et integrasjonslag mellom ERP-systemet og en privat integrator, mens ERP-systemet fortsatt er kildesystemet for kunder, varer, priser og regnskap.

Et strukturelt poeng som overrasker team som er nye i klarering, er at fakturaen ikke er ferdig når ERP-systemet skriver den ut. Den er ferdig når utvekslingen er fullført og svarene er kommet tilbake. Det betyr at ERP-systemets forståelse av fakturaens status må strekke seg lenger enn «opprettet» og «sendt» og også omfatte akseptert, avvist og korrigert. Virksomheter som hopper over dette, ender med å avstemme to versjoner av sannheten – hovedboken og det offisielle dokumentet – manuelt ved månedsslutt, selv om dette nettopp er arbeidet elektronisk fakturering skulle fjerne.

Et annet punkt gjelder tidspunkt. Dokumenter i et klareringssystem er ikke asynkrone på samme måte som et vedlegg i en e-post: Et avslag kommer mens teamet fortsatt arbeider, og korrigeringen det krever, berører vanligvis grunndata snarere enn selve dokumentet. Å bygge flyten slik at personen som kan rette årsaken, blir varslet med en gang, i stedet for å oppdage den i en månedsrapport, er forskjellen mellom et system som fungerer og et system som må overvåkes.

e-Fatura, e-Arşiv og e-İrsaliye forklart

Dokument	Brukes til	Typisk utløsende forhold	Merknad
e-Fatura	B2B- og virksomhet-til-myndighet-fakturaer mellom avgiftspliktige som er registrert for ordningen	Begge parter er registrert for e-Fatura	Et strukturert dokument som utveksles mellom registrerte parter; motpartens status avgjør ruten
e-Arşiv	Fakturaer der kjøperen ikke er registrert for e-Fatura – detaljhandel og B2C, samt enkelte B2B-forhold	Selgeren er omfattet; kjøperen står utenfor e-Fatura-regimet	Gjengis som PDF for kjøperen, men genereres og deklareres gjennom den samme kjeden
e-İrsaliye	Elektroniske leveringssedler for sektorene og transaksjonene som omfattes av reglene	Forsendelse av varer innenfor de omfattede flytene	Kobles til fakturaen: Leveringsseddelen og fakturaen viser til hverandre
e-Defter	Bøker og registre – hovedbok og dagbok, innsendt elektronisk	Omfattede avgiftspliktige, etter gjeldende regler	En separat plikt fra e-fakturering, men planlegges vanligvis i det samme prosjektet

Hvem som omfattes av hvilken plikt, defineres av GİB-regler og kunngjøringer, og disse endres. Grensene og sektorangivelsene fastsettes av myndighetene og endres sammen med reglene. Den riktige formuleringen overfor en kjøper er derfor prosedyremessig: Kontroller registreringsstatusen med regnskapsføreren eller skatterådgiveren opp mot gjeldende regler før integrasjonen utformes, ikke opp mot en artikkel – heller ikke denne.

Integrasjonsalternativer

Alternativ	Passer for	ERP-innsats	Forhold å følge med på
GİB-portalen	Svært små volumer, manuell utstedelse	Ingen i ERP-systemet	Manuelt og langsomt, og ikke et mål for en virksomhet med ERP; behold det bare som en reserve
Privat integrator (özel entegratör)	Den vanlige veien for de fleste virksomheter	En tilkobling til integratorens API eller format, samt mapping	Det er viktigere å sammenligne integratorer på support og API-kvalitet enn på logoen; spør hvem som vedlikeholder skjemaforandringene
Direkte GİB-tilgang	Større virksomheter som ønsker full kontroll	Høy: Dere overtar det tekniske og operative ansvaret for kanalen	Mer komplisert å få og drifte; beskrives som sjelden i praksis – behandle det som et unntak som må begrunnes, ikke som standard

Integratormodellen trenger en avklaring fordi den ofte misforstås: Bruk av en privat integrator overfører ikke den avgiftspliktiges plikter. Integratoren leverer den tekniske kanalen, overføringen og lagringstjenesten. Det juridiske ansvaret for dokumentene – at de er korrekte, at de utstedes og at de oppbevares etter skatteforvaltningsloven – ligger fortsatt hos den avgiftspliktige. Når en integrators salgsside får det til å høres ut som om etterlevelsesproblemet løses for dere, bør dere lese setningen en gang til.

I praksis viser dette skillet seg i små, konkrete situasjoner. Hvis et dokument avvises fordi kundens skatteidentifikator var feil i grunndataene deres, fungerte integratorens system som det skulle, og feilen må rettes av dere. Hvis en faktura utstedes med feil skattekode, vil ingen kanalkontroll redde dere. Integratoren er infrastruktur; datakvaliteten som går gjennom den, er en intern disiplin, og ERP-systemet er stedet der denne disiplinen enten bygges inn eller overlates til vane. Kjøpere som sammenligner integratorer, bør derfor bruke mindre tid på funksjonslisten og mer på spørsmålene som viser hvem som gjør hva når noe svikter: Hvem varsler hvem, i hvilket format og hvor raskt kan et korrigert dokument sendes på nytt?

Programvareutvikling: implementering og testing

En fungerende rekkefølge for en ERP-basert integrasjon:

Fastsett pliktenes omfang. Hvilke dokumenter gjelder for virksomheten – e-Fatura, e-Arşiv, e-İrsaliye, e-Defter – bekreftet mot gjeldende regler med selskapets regnskapsfører.

Velg kanal. De fleste virksomheter velger en privat integrator. Spørsmålene ved valget – API-kvalitet, tilgjengelig sandkasse, språk og åpningstider for support, håndtering av skjemaforandringer og referanser – fortjener en egen kortliste.

Kartlegg grunndata. Kunder og skatteidentifikatorer, varer, enheter, valutaer og skattekoder må mappes mot forventningene i skjemaet. Avvik her er den største enkeltkilden til senere feil.

Utform dokumentflyten. Hvem oppretter hva, når seglet brukes, hva som skjer ved feil, hvordan utgående og innkommende dokumenter kobles til ERP-registreringer, og hvordan korrigeringer utstedes.

Bruk testmiljøet. Begge sider tilbyr et testmiljø. Kjør alle dokumenttyper, alle feilflyter og alle korrigeringsscenarioer gjennom det før produksjonssetting, med den samme mappingen som brukes i produksjon.

Gjør feil til en prosess. Avvisninger kommer etter overføringen. Noen må se dem, forstå årsaken og korrigere de underliggende dataene – en varslingsinnboks uten en ansvarlig er slik en virksomhet ender med å utstede dokumenter for sent.

Planlegg arkivering og tilgang. Hvor dokumentene lagres, hvem som kan hente dem frem, og hvordan en forespørsel fra revisor besvares innenfor oppbevaringsperioden.

Det som avgjør om prosjektet lykkes, er ikke grensesnittet, men trinn 3, 6 og 7 – datakvalitet, ansvar for feil og gjenfinning – fordi dette fortsetter etter at prosjektteamet har gått videre.

Spørsmål om utenlandsk morselskap og ikke-bosatte til en rådgiver

For et selskap med utenlandsk morselskap, eller et selskap som går inn i Türkiye uten et fullt lokalt økonomiteam, hører flere spørsmål hjemme hos en skatterådgiver og ikke i IT-prosjektet. Svarene avgjør utformingen, så spør før integrasjonen starter og ikke etterpå:

Registreringsløp. Hvordan blir selskapet omfattet av pliktene, hvem signerer søknadene, og hvilken representant er godkjent – spørsmål om skatteregistrering, ikke programvare.

Ordning for seglet. Hvordan det finansielle seglet skaffes for selskapet, og hvordan oppbevaringen organiseres når signatarene befinner seg utenfor Türkiye.

Representanter og signaturer. Hvem har fullmakt til å signere hvilke dokumenter, og hva ERP-systemet må registrere om signataren i revisjonssporet.

Situasjonen for utenlandsk datterselskap. Om det gjelder ytterligere krav for selskaper med eiere som ikke er bosatt i landet, og hvordan fakturering innad i konsernet behandles.

Disse punktene er med hensikt formulert som spørsmål til en rådgiver: Regler for registrering og representasjon endres, de er lokale, og en produktside kan ikke kvalifisere dem. IT-prosjektet kan utforme løsningen for at svarene kommer sent – hold dokumentflyten konfigurerbar i stedet for å hardkode den rundt én antakelse.

Det lønner seg også å avgjøre hvem som eier forholdet til rådgiveren. I selskaper der økonomi og IT begge antar at den andre har stilt spørsmålet, kommer disse punktene sent inn i integrasjonen – vanligvis i ukene før produksjonssetting, når dokumentflyten allerede er fastlagt. En navngitt ansvarlig på hver side og ett felles møte før trinn 3 i implementeringen forhindrer det meste.

Vanlige problemer

Feilene som oftest oppstår i denne typen prosjekt, og hva hver av dem vanligvis peker på:

Avvisninger ved validering. Nesten alltid et mappingproblem: En skattekode, et identifikatorformat eller et felt på linjenivå samsvarer ikke med forventningen i skjemaet. Rett grunndataene, ikke logikken for nye forsøk.

Duplisert nummerering. Nummerserier som genereres av mer enn ett system, eller genereres på nytt etter en feil. Nummereringen må ha nøyaktig én eier og en dokumentert regel for gjenoppretting.

Feil i motpartens status. Feil dokumenttype utstedes fordi kundens registreringsstatus ble lagret i hurtigbuffer eller antatt. Slå opp statusen etter integratorens regler i stedet for å stole på hukommelsen.

Innkommende dokumenter går tapt. Dokumenter mottas, men bokføres aldri tilbake i ERP-systemet, slik at leverandørreskontroen arbeider fra et separat skjermbilde. Utvekslingsretningen er en del av integrasjonen, ikke et valgfritt tillegg.

Skjemaforandringer overses. Strukturen endres over tid. Den ansvarlige må vite når den ble endret, og hvilken virkning endringen fikk på mappingen.

Testing hoppes over på grunn av tidsfristen. Alle problemene over er billigere å håndtere i testmiljøet. Presset før produksjonssetting er stedet der de blir til hendelser.

Vanlige spørsmål

Hva er forskjellen mellom e-Fatura og e-Arşiv?

e-Fatura omfatter fakturaer som utveksles mellom avgiftspliktige som er registrert i ordningen, som strukturerte dokumenter mellom registrerte parter. e-Arşiv omfatter fakturaer der kjøperen står utenfor ordningen – detaljhandel og B2C, samt enkelte B2B-forhold – og kjøperen mottar dem vanligvis som en PDF generert gjennom den samme offisielle kjeden. Hvilken ordning som gjelder for en bestemt faktura, følger av motpartens registreringsstatus. Derfor kontrollerer integrasjonen statusen i stedet for å anta.

Trenger jeg en privat integrator?

For de fleste virksomheter, ja – det er den vanlige veien, mens den direkte kanalen beskrives som komplisert og sjelden. En privat integrator leverer den tekniske kanalen til GİB og lagringstjenesten, men pliktene deres som avgiftspliktig forblir deres. Valg av integrator er en innkjøpsprosess: API-kvalitet, sandkasse, support og håndtering av skjemaforandringer avgjør den daglige opplevelsen mer enn merkevaren.

Hva er det finansielle seglet (mali mühür)?

Det er den avgiftspliktiges digitale signeringslegitimasjon, som brukes til å signere elektroniske dokumenter før de overføres. Oppbevaring og hvem som kan bruke seglet, er praktiske spørsmål som må avklares internt i selskapet. For team med signatarer utenfor Türkiye er ordningen for hvem som oppbevarer og bruker seglet, et av de første punktene som bør tas opp med en skatterådgiver.

Kan alle ERP-systemer utstede tyrkiske e-fakturaer?

Nei. ERP-systemet må generere den påkrevde UBL-TR-strukturen med korrekte grunndata, eller være koblet til en motor eller integrator som gjør det. Et standard fakturaoppsett er ikke tilstrekkelig. De fleste virksomheter kobler seg derfor til i stedet for å bygge om: Spør leverandøren hvilke integratorer koblingen støtter, hva den mapper, og hvor dokumentasjonen finnes.

Hvordan tester jeg før produksjonssetting?

Gjennom testmiljøene som både integratoren og den offisielle siden tilbyr, med den samme mappingen av grunndata som i produksjon: alle dokumenttyper, alle avvisningsflyter, alle korrigeringer og alle innkommende dokumenter som føres tilbake til ERP-systemet. Behandle testen som en øvelse i feilprosessen også. Noen må motta, diagnostisere og rette en avvisning, ikke bare se et grønt merke.

Hvem lagrer fakturaene?

Den avgiftspliktige er fortsatt ansvarlig for oppbevaringen etter skatteforvaltningsloven. Integratoren tilbyr vanligvis teknisk lagring, og mange virksomheter oppbevarer også dokumentene i ERP-systemet for daglig bruk. Det viktige er å bestemme ordningen før produksjonssetting, vite hvem som kan fremskaffe hvert dokument i oppbevaringsperioden, og teste gjenfinningen før en revisor ber om det.

Kilder og standarder

GİB – Gelir İdaresi Başkanlığı – skatteforvaltningen publiserer reglene, kommunikeene og den tekniske dokumentasjonen for e-Fatura, e-Arşiv, e-İrsaliye og e-Defter. De gjeldende versjonene der har forrang foran alt som er oppsummert på denne siden.
Registreringsstatus, grenser, sektorangivelser og frister fastsettes av myndighetene og endres. Bekreft dem med regnskapsføreren eller skatterådgiveren opp mot gjeldende regler. Ingenting på denne siden er skatterådgivning, og det hevdes ikke noe integratorforhold, partnerskap eller sertifisering for WorldwideTradeX.

Relaterte sider

Programvareutvikling · Odoo ERP for handelsbedrifter · Tilpasset eller standardisert ERP · IT-revisjon og rådgivning · Be om tilbud