Türkiye e-faktura og ERP-system i softwareudvikling

For at drive virksomhed i Türkiye skal et ERP-system normalt understøtte e-Fatura og e-Arşiv — og e-İrsaliye i visse sektorer — gennem Revenue Administration (GİB), typisk via en privat integrator. ERP-systemet opretter dokumentet i UBL-TR-format, sælgeren underskriver det med det finansielle segl (mali mühür), integratoren cleare det hos GİB, og skatteyderen er fortsat ansvarlig for opbevaringen hele vejen.

Hvad skal et ERP-system understøtte i Türkiye?

Türkiye anvender elektronisk fakturering som et clearingsystem: Sælgeren opretter et dokument, sender det gennem en godkendt kanal, Revenue Administration validerer det, og først derefter har det juridisk virkning. For en virksomhed, der driver sine aktiviteter på et ERP-system, har det konsekvenser fire steder i systemet:

• Oprettelse af dokumentet. ERP-systemet — eller en tilsluttet motor — skal generere fakturaer i den krævede UBL-TR-struktur med de koder, partidentifikatorer og linjedata, som skemaet kræver, ikke et printlayout, der er omformet til XML.


• Digital underskrift. Dokumenter underskrives med det finansielle segl, der er udstedt til skatteyderen; underskriftstrinnet skal indgå i flowet med nøglehåndtering, der passer til reglerne for seglets opbevaring.


• Tovejsudveksling. I e-Fatura-ordningen afgør modpartens registreringsstatus dokumenttypen, og indgående dokumenter — modtagne fakturaer, svar og annulleringer, hvor det er tilladt — skal tilbage i ERP-systemet med deres oprindelige identifikatorer. Ellers mister regnskabet forbindelsen mellem systemet og det officielle dokument.


• Arkivering og hentning. Udstedte og modtagne dokumenter skal kunne hentes i den lovpligtige opbevaringsperiode. Om integratoren, ERP-systemet eller begge gemmer dem, skal besluttes før go-live og ikke efter en revisionsanmodning.

Et strukturelt punkt overrasker teams, der er nye i clearing: Fakturaen er ikke færdig, når ERP-systemet udskriver den. Den er færdig, når udvekslingen er gennemført, og svarene er kommet tilbage. Det betyder, at ERP-systemets opfattelse af en fakturas status skal gå videre end "oprettet" og "sendt" og også omfatte accepteret, afvist og korrigeret. Virksomheder, der springer dette over, ender med manuelt at afstemme to versioner af sandheden — deres finansbog og den officielle registrering — ved månedens udgang, præcis det arbejde elektronisk fakturering skulle fjerne.

Et andet punkt handler om timing. Dokumenter i et clearingsystem er ikke asynkrone på samme måde som en vedhæftet e-mail: En afvisning kommer, mens teamet stadig arbejder, og den krævede rettelse berører normalt stamdata snarere end selve dokumentet. At bygge flowet, så den person, der kan rette årsagen, får besked med det samme i stedet for at opdage den i en månedsrapport, er forskellen på et system, der kører, og et system, der kræver konstant overvågning.

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

Hvem der falder under hvilken forpligtelse, defineres af GİB-regler og bekendtgørelser, som ændrer sig. Tærskler og sektorudpegninger fastsættes af myndighederne og ændres sammen med reglerne. Den korrekte formulering til en køber er derfor proceduremæssig: Kontrollér registreringsstatus med virksomhedens revisor eller skatterådgiver efter de aktuelle regler, før integrationen designes, ikke efter en artikel — heller ikke denne.

Integrationsmuligheder

Integratormodellen kræver en præcisering, fordi den ofte misforstås: Brug af en privat integrator overfører ikke skatteyderens forpligtelser. Integratoren leverer den tekniske kanal, transmissionen og lagringstjenesten; det juridiske ansvar for dokumenterne — deres korrekthed, udstedelse og opbevaring efter Tax Procedure Law — bliver hos skatteyderen. Når en integrators salgsside lyder, som om complianceproblemet bliver løst for jer, så læs den sætning igen.

I praksis viser denne opdeling sig i små, konkrete forhold. Hvis et dokument afvises, fordi kundens skatteidentifikator var forkert i jeres stamdata, fungerede integratorens system perfekt, og fejlen er jeres at rette. Hvis en faktura udstedes med den forkerte skattekode, kan ingen kanalvalidering redde jer. Integratoren er infrastruktur; datakvaliteten, der løber igennem den, er en intern disciplin, og ERP-systemet er stedet, hvor disciplinen enten bygges ind eller overlades til vaner. Købere, der sammenligner integratorer, bør derfor bruge mindre tid på funktionslisten og mere på spørgsmål, der viser, hvem der gør hvad, når noget fejler: Hvem alarmerer hvem, i hvilket format, og hvor hurtigt kan et korrigeret dokument sendes igen?

Implementeringstrin og test i softwareudvikling

En brugbar rækkefølge for en ERP-sideintegration:

1. Fastlæg forpligtelsernes omfang. Hvilke dokumenter gælder for virksomheden — e-Fatura, e-Arşiv, e-İrsaliye, e-Defter — bekræftet efter de aktuelle regler med virksomhedens revisor.


2. Vælg kanalen. De fleste virksomheder vælger en privat integrator; spørgsmålene ved valget — API-kvalitet, tilgængeligt sandboxmiljø, supportsprog og åbningstider, håndtering af skemaopdateringer og referencer — fortjener deres egen shortlistøvelse.


3. Map stamdata. Kunder og deres skatteidentifikatorer, varer, enheder, valutaer og skattekoder skal mappes til skemaets forventninger; uoverensstemmelser her er den største enkeltkilde til senere fejl.


4. Design dokumentflowet. Hvem opretter hvad, hvornår seglet anvendes, hvad der sker ved fejl, hvordan udgående og indgående dokumenter matches med ERP-poster, og hvordan rettelser udstedes.


5. Brug testmiljøet. Begge sider tilbyder et testmiljø; kør alle dokumenttyper, alle fejlveje og alle rettelsesscenarier igennem før go-live med den samme mapping, som bruges i produktionen.


6. Håndtér fejl som en proces. Afvisninger kommer efter transmissionen; nogen skal se dem, forstå årsagen og rette de underliggende data — en alarmindbakke uden en ejer er sådan, en virksomhed ender med at udstede dokumenter for sent.


7. Planlæg arkivering og adgang. Hvor dokumenter gemmes, hvem der kan hente dem, og hvordan en revisors anmodning besvares inden for opbevaringsperioden.

Spørgsmål for udenlandsk moderselskab og ikke-hjemmehørende virksomhed

For en virksomhed med et udenlandsk moderselskab eller en virksomhed, der går ind i Türkiye uden et fuldt lokalt økonomiteam, hører flere spørgsmål hjemme hos en skatterådgiver og ikke i IT-projektet — svarene bestemmer designet, så spørg før integrationen starter og ikke bagefter:

• Registreringsvej. Hvordan bliver virksomheden omfattet af forpligtelserne, hvem underskriver ansøgningerne, og hvilken repræsentant anerkendes — spørgsmål om skatteregistrering og ikke software.


• Seglaftaler. Hvordan anskaffes det finansielle segl til virksomheden, og hvordan organiseres opbevaringen, når underskrivere befinder sig uden for Türkiye.


• Repræsentanter og underskrifter. Hvem er bemyndiget til at underskrive hvilke dokumenter, og hvad skal ERP-systemet registrere om underskriveren i revisionssporet.


• Den udenlandske datterselskabsposition. Om der gælder yderligere krav for virksomheder med ikke-hjemmehørende ejere, og hvordan fakturering internt i koncernen behandles.

Det kan også betale sig at beslutte, hvem der ejer relationen til rådgiveren. I virksomheder, hvor økonomi og IT begge antager, at den anden har stillet spørgsmålet, kommer disse punkter sent ind i integrationen — normalt i ugerne før go-live, når dokumentflowet allerede er fastlagt. En navngiven ejer på hver side og ét fælles møde før trin 3 i implementeringen forebygger det meste.

Almindelige problemer

De fejl, der oftest viser sig i denne type projekt, og hvad de normalt peger på:

• Afvisninger ved validering. Næsten altid et mappingproblem: En skattekode, et identifikatorformat eller et felt på linjeniveau, der ikke matcher skemaets forventning. Ret stamdataene og ikke retry-logikken.


• Dobbelt nummerering. Nummersekvenser genereret af mere end ét system eller genereret igen efter en fejl; nummereringen skal have præcis én ejer og en dokumenteret gendannelsesregel.


• Fejl i modpartens status. Den forkerte dokumenttype udstedes, fordi kundens registreringsstatus blev cachet eller antaget; slå status op efter integratorens regler i stedet for efter hukommelsen.


• Indgående dokumenter går tabt. Dokumenter modtages, men bogføres aldrig tilbage i ERP-systemet, så kreditorbogholderiet arbejder fra en separat skærm; udvekslingsretningen er en del af integrationen og ikke en valgfri ekstra funktion.


• Skemaopdateringer overses. Strukturen ændrer sig over tid; den ansvarlige skal vide, hvornår den ændrede sig, og hvad ændringen gjorde ved mappingen.


• Test springes over på grund af deadline. Alle ovenstående problemer er billigere i testmiljøet; go-live-pres er det sted, hvor de bliver til hændelser.

Ofte stillede spørgsmål

Hvad er forskellen på e-Fatura og e-Arşiv?

e-Fatura dækker fakturaer, der udveksles mellem skatteydere, som er registreret til ordningen, som strukturerede dokumenter mellem registrerede parter. e-Arşiv dækker fakturaer, hvor køberen er uden for ordningen — detailhandel og B2C samt visse B2B-handler — og som køberen typisk modtager som en PDF genereret gennem den samme officielle kæde. Hvilken ordning der gælder for en faktura, følger af modpartens registreringsstatus, og derfor kontrollerer integrationen den i stedet for at antage den.

Har jeg brug for en privat integrator?

For de fleste virksomheder, ja — det er den almindelige vej, mens den direkte kanal beskrives som kompleks og sjælden. En privat integrator leverer den tekniske kanal til GİB og lagringstjenesten; jeres forpligtelser som skatteyder forbliver jeres. Valget er en indkøbsøvelse: API-kvalitet, sandbox, support og håndtering af skemaopdateringer afgør den daglige oplevelse mere end brandet.

Hvad er det finansielle segl (mali mühür)?

Det er skatteyderens digitale underskriftscredential, der bruges til at underskrive elektroniske dokumenter, før de sendes. Opbevaring og hvem der må bruge det, er praktiske spørgsmål, som skal afklares internt i virksomheden. For teams med underskrivere uden for Türkiye er aftalen om, hvem der opbevarer og anvender seglet, et af de første punkter, der skal forelægges en skatterådgiver.

Kan ethvert ERP-system udstede tyrkiske e-fakturaer?

Nej. ERP-systemet skal generere den krævede UBL-TR-struktur med korrekte stamdata eller være forbundet med en motor eller integrator, der gør det; et standardfakturalayout er ikke nok. De fleste virksomheder forbinder derfor i stedet for at genopbygge — spørg en leverandør, hvilke integratorer deres connector understøtter, hvad den mapper, og hvor dokumentationen findes.

Hvordan tester jeg før go-live?

Via de testmiljøer, som både integratoren og den officielle side stiller til rådighed, med den samme stamdatamapping som i produktionen: alle dokumenttyper, alle afvisningsveje, alle rettelser og alle indgående dokumenter, der bogføres tilbage i ERP-systemet. Betragt også testen som en øvelse i fejlprocessen: Nogen skal modtage, diagnosticere og rette en afvisning, ikke kun se et grønt flueben.

Hvem opbevarer fakturaerne?

Skatteyderen er fortsat ansvarlig for opbevaringen efter Tax Procedure Law; integratoren leverer typisk teknisk lagring, og mange virksomheder gemmer også dokumenter i deres ERP-system til daglig brug. Det afgørende er at beslutte ordningen før go-live, vide hvem der kan fremskaffe hvilket dokument inden for opbevaringsperioden og teste hentningen, før en revisor spørger efter det.

Kilder og standarder

• GİB — Gelir İdaresi Başkanlığı — Revenue Administration offentliggør regler, bekendtgørelser og teknisk dokumentation for e-Fatura, e-Arşiv, e-İrsaliye og e-Defter; de aktuelle versioner dér erstatter alt, der er opsummeret på denne side.
• Registreringsstatus, tærskler, sektorudpegninger og frister fastsættes af myndighederne og ændrer sig; bekræft dem med virksomhedens revisor eller skatterådgiver efter de aktuelle regler. Intet på denne side er skatterådgivning, og der hævdes ingen integratorrelation, partnerskab eller certificering for WorldwideTradeX.

Relaterede sider

Softwareudvikling · Odoo ERP til handelsvirksomheder · Specialudviklet kontra pakket ERP · IT-audit og rådgivning · Anmod om tilbud