Österreich
- Tina Sunjic (Unlicensed)
- Lukas Schwalvenberg
- Dennis
Fristen
- Die Frist für die Abgabe der Umsatzsteuervoranmeldnung in Österreich ist für alle Unternehmen der 15. des zweit-folgenden Monats. Die Januar-Voranmeldung muss entsprechend bis zum 15. März eingereicht werden. In Österreich gibt es keine Dauerfristverlängerung, um die Frist zu verschieben, weshalb auch keine Sondervorauszahlung nötig ist.
- Die Umsatzsteuererklärung ist bis zum 30. April des Folgejahres bzw. bei elektronischer Übermittlung über FinanzOnline bis zum 30. Juni des Folgejahres einzureichen (§ 134 Abs 1 Bundesabgabenordnung – BAO). Im Einzelfall kann auf begründeten Antrag die Frist zur Abgabe der Steuererklärung verlängert werden (§ 134 Abs 2 BAO).
Meldung
In der Meldung gibt es die Möglichkeit, eine Kundeninformation zu hinterlegen. Dieses Feld ist optional zu befüllen. Der Inhalt dieses Feldes wird im Ergebnisprotokoll rückübermittelt und kann beispielsweise zur Kennzeichnung des Versenders im Falle einer Archivierung dieses Protokolls dienen.
Mehrfachmapping
In Österreich werden in Feld 000 und 001 der Gesamtbetrag der Bemessungsgrundlagen für Lieferungen und Leistungen eingetragen. Diese Werte werden in der Meldung anschließend weiter aufgeschlüsselt. Daher müssen Steuerkennzeichen, die solche Sachverhalte beschreiben, auf verschiedene Felder in der Meldung gemappt werden. Dazu kann ein Mehrfachmapping angelegt werden. Die folgenden Felder sind davon betroffen:
Gesamtbetrag der Bemessungsgrundlagen | Aufschlüsselung |
---|---|
Feld 000 oder 001 | 021, 011, 012, 015, 017, 018, 019, 016, 020, 022, 029, 006, 037, 052, 007, 009 |
Jedes Steuerkennzeichen, dass auf eines dieser Felder gemappt wird, muss zudem auf ein Feld der anderen Seite gemappt werden. Beim Import eines Steuerkennzeichen-Mappings im Dialog [Stammdaten → Steuerkennzeichen] muss ein solches Steuerkennzeichen in der Import-Datei doppelt vorhanden sein, damit beide Mappingpositionen importiert werden können.
Im Dialog [Stammdaten → Steuerkennzeichen Mapping] kann eine Validierung der Steuerkennzeichen durchgeführt werden. Dabei wird unter anderem diese Mapping-Regel validiert.
Praxishinweis
Wird diese Regel nicht eingehalten, können die Funktionen zu Entgeltsänderungen und die Übernahme der Voranmeldungswerte in die Jahreserklärung nicht gewährleistet werden.
Entgeltsänderungen
In der österreichischen Meldung kann nur auf den Feldern 063, 067 und 090 ein negativer Betrag übermittelt werden. Sobald ein Feld in der kumulierten Meldung eines OGK oder in einer Standalone Meldung negativ ist, muss ein negativer Betrag (eine Entgeltsänderung) mitberücksichtigt worden sein, der in diesem Fall aber anders zu melden ist. Deswegen nimmt das VAT@GTC beim Abschluss einer OGK oder Standalone Meldung eine automatische Gegenbuchung bzw. Umbuchung vor. Darauf weist auch eine Info im VAT@GTC hin: „Es sind negative Werte in den Feldern 029a vorhanden, welche bei Abschluss der Meldung automatisch umgetragen werden. Bitte überprüfen Sie die Korrektheit dieser Änderungen nach Abschluss der Meldung.“ Beim erneuten Öffnen der Meldungen werden alle Umbuchungen wieder gelöscht, sodass die Umbuchungen immer anhand des finalen Standes der Meldung getätigt werden können.
Praxishinweis
In rein manuellen Standalones steht diese Funktion nicht zur Verfügung. Hier müssen die Werte direkt korrekt eingetragen werden. Grundsätzlich empfiehlt AMANA, die Meldung immer die Meldung mit Steuerkennzeichenmappings zu erstellen, auch wenn die Werte nicht automatisiert hochgeladen werden können.
Grundsätzlich gilt, dass in Feld 067 negative Vorsteuerbeträge und in Feld 090 negative Steuerbeträge eingetragen werden können. Bemessungsgrundlagen, die zu einem negativen Wert führen, sollen in der Meldung nicht berücksichtigt werden. Das Problem dabei ist, dass diese zu diesem Zeitpunkt berücksichtigt wurden. Daher müssen negative Einträge gegengebucht werden, sodass die Summe des Feldes 0 beträgt. Sobald ein negativer Steuerwert vorhanden ist, muss auch dieser im ursprünglichen Feld auf 0 gesetzt werden und zusätzlich auf Feld 067 bzw. 090 eingetragen werden. Bei der Umbuchung werden drei Schritte angewendet:
Schritt 1: Eigenes Feld auf 0,00€ setzen
Das Feld, in dem der negative Wert vorkommt, muss immer auf 0,00€ gesetzt werden.
Schritt 2: Wurde der Eintrag in weiteren Feldern berücksichtigt?
Es gibt in der Meldung einige Sachverhalte, die auf mehreren Feldern berücksichtigt werden müssen. Handelt es sich bei dem Feld um einen Sachverhalt, der auch in anderen Feldern einfließt, muss der gleiche Wert, der im ersten Schritt gegengebucht wurde, auch im weiteren Feld gegengebucht werden. Hierbei gibt es drei Fälle:
- Der Wert dieses Feldes wird grundsätzlich in Feld 000 oder Feld 001 berücksichtigt: Da Feld 001 für Entgeltsänderungen grundsätzlich keine Rolle spielt, wird die Gegenbuchung in diesem Fall auch in Feld 000 eingebracht.
- Der Wert des Feldes wird auch in Feld 070 berücksichtigt: Das VAT@GTC berechnet dieses Feld automatisch als Summe, daher ist hier keine explizite Gegenbuchung nötig.
- Der Wert des Feldes fließt in kein weiteres Kennzeichen ein: In diesem Fall wird dieser Schritt übersprungen.
Praxishinweis
Automatisch berechnete Summenfelder ohne Kennziffer sind hier nicht gemeint.
Schritt 3: Ist eine Steuer zum Umbuchen vorhanden?
Hat bzw. ist das Feld ein Steuerfeld, so muss der Wert in der Meldung zudem in eines der Kennzeichen umgetragen werden, auf dem negative Werte erlaubt sind, damit die errechnete Steuer sich nicht verändert. Hierbei gibt es 3 Möglichkeiten:
- Negative Ausgangssteuer wird negativ auf Feld 090 umgebucht.
- Negative Vorsteuer wird positiv auf Feld 067 umgebucht (Die Summe der Vorsteuer wird negativ errechnet).
- Negative, nicht abzugsfähige Vorsteuer (Feld 062) wird negativ auf Feld 067 umgebucht.
Aus diesen Schritten ergeben sich 8 verschiedene Fälle, die behandelt werden:
Fall | Eigenes Feld auf Null setzen | Wurde der Eintrag in weiteren Feldern berücksichtigt? | Ist eine Steuer zum umbuchen vorhanden? |
---|---|---|---|
Fall 1: Steuerfreie Umsätze (Und Feld 021) (021,011-020) | Ja | Wird zusätzlich in Feld 000 gegengebucht. | Nein |
Fall 2: Steuerbare Umsätze (022-009) | Ja | Wird zusätzlich in Feld 000 gegengebucht. | Umbuchung der Steuer in Feld 090 |
Fall 3: Weiters zu versteuern (056-032) | Ja | Nein | Umbuchung der Steuer in Feld 090 |
Fall 4: Innergemeinschaftliche Erwerbe ohne Steuerfeld (071) | Ja | Wird in 070 als Summe ohne Gegenbuchung korrekt errechnet. | Nein |
Fall 5: Steuerbare Innergemeinschaftliche Erwerbe (072-010) | Ja | Wird in 070 als Summe ohne Gegenbuchung korrekt errechnet. | Umbuchung der Steuer in Feld 090 |
Fall 6: Nicht zu Versteuernde Erwerbe (076, 077) | Ja | Nein | Nein |
Fall 7: Vorsteuer (060-064) | Ja | Nein | (Positive) Umbuchung der Vorsteuer in Feld 067 |
Fall 8: Nicht abzugsfähige Vorsteuer (062) | Ja | Nein | (Negative) Umbuchung der Vorsteuer in Feld 067 |
Jahreserklärung
Die Übernahme der Voranmeldungswerte in die Jahreserklärung erfolgt über Mappings, und kann nicht einfach aufsummiert werden. Das liegt unter anderem daran, dass Entgeltsänderungen sonst nicht berücksichtigt würden.
Hauptfeldmapping
Bei rein manuellen Meldern erfolgt die Übernahme in die Jahreserklärung über ein Hauptfeldmapping. Hierbei sind fast alle Felder der Voranmeldung im Standard bereits hinterlegt. Lediglich die Felder 067 und 090 werden nicht in die Jahreserklärung übernommen, da Umbuchungen aus Entgeltsänderungen in der Jahreserklärung neu betrachtet werden müssen. Daher kann es auch sein, das andere Felder nach dem Übertrag aufgrund von Entgeltsänderungen noch angepasst werden müssen. AMANA empfiehlt daher immer, auch bei manuellen Meldern Steuerkennzeichen zu verwenden.
Steuerkennzeichen Mapping
Werden Steuerkennzeichen verwendet, ist zu beachten, dass das komplette Steuerkennzeichen-Mapping auch in der Jahreserklärung vorhanden sein muss, da die Steuerkennzeichen aus der Voranmeldung zunächst aufsummiert werden und anschließend über das Mapping in der Jahreserklärung wieder auf die Felder zugeordnet werden. Umbuchungen aus Entgeltsänderungen werden nicht in die Jahreserklärung übernommen, da Entgeltsänderungen in der Jahreserklärungen auf das ganze Jahr hin betrachtet werden. Falls aus der Kumulierung der Steuerkennzeichen in die Jahreserklärung noch immer negative Werte aus Entgeltsänderungen stehen bleiben, werden beim Abschluss der Meldung entsprechend auch in der Jahreserklärung umgebucht.
Anzahl Gesellschaften
Bei der Jahreserklärung wird zudem die Summe aller untergeordneten Gesellschaften automatisch ermittelt und übermittelt. Damit diese Kennziffer korrekt ermittelt werden kann ist es wichtig, dass alle Existierenden Gesellschaften im Organkreis als Organträger/Zwischenorganträger/Organgesellschaften angelegt werden. Wenn eine Gesellschaft mehrere Buchungskreise hat, müssen diese auch immer als Teilgesellschaften angelegt werden, sonst würden sie mitgezählt.
Korrekturen
Eine Korrektur der Voranmeldung in Österreich kann einmal elektronisch eingereicht werden. Die Berichtigung erfolgt durch Einreichen einer neuen vollständigen Umsatzsteuervoranmeldung.
Wenn nach der ersten Korrektur weitere Berichtigungen nötig werden, können diese nicht mehr elektronisch über die Schnittstellen versendet werden, sondern müssen per Post eingereicht werden.
Abstimmungen
Zusätzlich zu den Abstimmungen, die in jedem Land verfügbar sind (1,3,4,5,6,7,8,10) können die folgenden Abstimmungen für Österreich durchgeführt werden:
- Abstimmung 2: Vergleicht Kennziffer 095 mit dem Zahllastkonto aus dem RFBILA00.
- Abstimmung 12: Stimmt die Reverse Charge Sachverhalte ab. Verglichen werden die Ausgangs-Kennziffern 057, 048, 044 und 032 mit den entsprechenden Vorsteuer-Kennziffern 066, 082, 087 und 089.
- Abstimmung 13: Stimmt die innergemeinschaftlichen Erwerbe ab. Verglichen werden die Ausgangs-Kennziffern 072, 073, 008, 088 und 010 mit der entsprechenden Vorsteuer-Kennziffer 065.
Versand der Meldung
Voraussetzungen
Der Versand der Meldung an FinanzOnline ist direkt aus dem VAT@GTC möglich.
Praxishinweis
Um eine Meldung versenden zu können, muss zwingend eine Steuernummer eingetragen werden. Die Steuernummer muss neun Ziffern haben und setzt sich aus den zwei Ziffern der Finanzamtsnummer und der eigenen Steuernummer zusammen. Im VAT@GTC müssen Leerzeichen und Schrägstriche weggelassen werden, die Schnittstelle erwartet nur die neun Ziffern.
Damit ein Nutzer eine Meldung an FinanzOnline übermitteln kann, braucht er einen Zugang vom österreichischen Finanzamt. Dieser Zugang benötigt in FinanzOnline die Freischaltung für den Webservice. Ein solcher Zugang mit Webservice Freischaltung muss im VAT@GTC im Dialog [Einstellungen → Zugangsdaten] pro Nutzer, der versenden soll, hinterlegt werden. Dazu muss ein Zugangsdatum mit der Kategorie REST-Service angelegt werden:
Einstellung | Bedeutung |
---|---|
ID | Die ID des Zugangsdatums. |
User-ID | Die ID des VAT@GTC Users. |
Login | Der Login des VAT@GTC Users. |
Benutzername | Der Benutzername des persönlichen oder technischen FinanzOnline Zugangs. |
Passwort | Das Passwort des persönlichen oder technischen FinanzOnline Zugangs. |
Kategorie | Hier muss REST-Service angegeben werden. |
Teilnehmer-Identifikation | Die Teilnehmer-Identifikation des FinanzOnline-Unternehmensaccounts. Wenn ein Nutzer Gesellschaften in verschiedenen Unternehmens-Accounts betreut, braucht dieser daher auch mehrere Einträge unter Zugangsdaten. |
Verbindungsparameter | Die Schnittstelle zu FinanzOnline, die im Dialog [Einstellungen → Verbindungsparameter] konfiguriert ist. |
Gesellschaften | Hier kann eine oder mehrere Gesellschaften hinterlegt werden, für die dieser Zugang gültig ist. Pro Benutzer kann jede Gesellschaft maximal in einem FinanzOnline Zugang hinterlegt sein. |
Versandprozess
Wenn der Versand durchgeführt, gibt es, anders als in Deutschland, lediglich eine technische Rückmeldung, ob die Meldung eingegangen ist. Damit ist allerdings noch nicht bestätigt, ob die Meldung tatsächlich von FinanzOnline akzeptiert wird. Erst später wird vom Finanzamt geprüft, ob die Übermittlung fachlich auch valide ist. Sobald dieser Prozess abgeschlossen ist, wird ein Protokoll von FinanzOnline erstellt. Dieses Protokoll kann über die Schaltleiste [Protokolle abrufen] abgerufen werden. Bis zur Bereitstellung der Protokolle kann es einige Stunden dauern.
In diesem Protokoll ist dann schlussendlich vermerkt, ob die Meldung von FinanzOnline übernommen wurde.
Praxishinweis
Es gibt beim Testversand einzelne Felder, die nicht vollständig überprüft werden. Die Steuernummer wird beim Testversand bspw. nur darauf überprüft, ob eine vorhanden ist und ob sie aus 9 Ziffern besteht. Ob es sich um eine existierende Steuernummer handelt, wird beim Testversand nicht überprüft. Daher ist der Produktiv Versand nicht zwangsweise erfolgreich, wenn der Testversand erfolgreich war.
Für den Produktivversand bedeutet dass, das der Status der Meldung bei der Durchführung der Versendung zunächst auf [In Versendung] gesetzt wird. Gibt es beim Versand technische Probleme, sodass die Meldung nicht bei FinanzOnline eingeht, so bleibt der Status auf geschlossen und der Versand kann nach Lösung dieser Probleme erneut durchgeführt werden.
Sobald der Status der Meldung auf [In Versendung] ist, kann er nur mit dem Protokollabruf wieder geändert werden. Wenn das Produktivprotokoll erfolgreich abgerufen wurde, gibt es zwei Möglichkeiten:
- Die Meldung ist fachlich valide und wurde von FinanzOnline übernommen. Der Status der Meldung wechselt in diesem Fall auf [Versendet].
- Die Meldung ist fachlich nicht valide und kann nicht angenommen werden, der Grund dafür ist im Protokoll hinterlegt. Der Status der Meldung wird auf [Send Error] gesetzt. Ein entsprechend berechtigter User muss nun den Status der Gesellschaft wieder auf geschlossen, bzw. offen setzen. Anschließend kann überprüft und behoben werden, was an der Meldung fehlerhaft ist. Danach kann der Versandprozess erneut begonnen werden.
Praxishinweis
Da die ursprüngliche Meldung nicht als eingebracht gilt, wenn das Protokoll die Rückmeldung gibt, dass es noch einen Fehler gibt, handelt es sich bei der erneuten Übermittlung nicht um eine Korrektur Übermittlung.
Da das Protokoll von FinanzOnline die Übermittelte Meldung nicht enthält, wird zur genaueren Nachverfolgung und Dokumentation automatisch ein PDF-Export der Meldung im VAT@GTC erstellt und in die Dokumentenliste des Dialogs [Meldung versenden] aufgenommen. Diesem PDF wird eine Transfer ID zugeteilt, die auch die Übermittlung erhält. Anhand dieser kann ein PDF der Meldung dem entsprechenden Protokoll von FinanzOnline zugeordnet werden. Sobald das Protokoll abgerufen wird, ist es mit der PDF der Meldung gruppiert in der Dokumentenliste zu finden. So können verschiedene Test bzw. Produktivversände einer Gesellschaft voneinander unterschieden werden.
Deadlines
The deadline for submitting the preliminary VAT return in Austria is the 15th of the second month following the month in question for all companies. Accordingly, the January advance return must be submitted by 15 March. In Austria there is no permanent deadline extension to postpone the deadline, which is why no special advance payment is necessary.
The annual declaration must be submitted by 30 April of the following year or, in the case of electronic transmission via FinanzOnline, by 30 June of the following year (§ 134 (1) of the Federal Fiscal Code - BAO). In individual cases, the deadline for submitting the tax return can be extended upon justified request (§ 134 para. 2 BAO).
Declaration
In the declaration there is the possibility to store customer information. This field is optional. The content of this field is transferred back in the results log and can, for example, be used to identify the sender if the log is archived.
Multiple Mappings
In Austria, the total amount of the tax assessment bases for supplies and services is entered in field 000 and 001. These values are then further broken down in the declaration. Therefore, tax codes describing such matters must be mapped to different fields in the declaration. A multiple mapping can be created for this purpose. The following fields are affected:
Total amount of the tax assessment bases | Breakdown |
---|---|
Field 000 or 001 | Fields 021, 011, 012, 015, 017, 018, 019, 016, 020, 022, 029, 006, 037, 052, 007, 009 |
Each tax code that is mapped to one of these fields must also be mapped to a field on the other side. When importing a tax code mapping in the [Master Data → Tax Codes] dialogue, such a tax code must exist twice in the import file so that both mapping positions can be imported.
In the dialogue [Master Data → Tax Code Mapping], a validation of the tax codes can be carried out. Among other things, this mapping rule is checked.
Good to know
If this rule is not followed, the functions for fee changes and the transfer of the preliminary declaration values to the annual declaration cannot be guaranteed.
Fee changes
In the Austrian declaration, a negative amount can only be transmitted in fields 063, 067 and 090. As soon as a field in the cumulative declaration of a VAT group or in a standalone declaration is negative, a negative amount (a fee change) must have been taken into account, which in this case must be reported differently. For this reason, the VAT@GTC makes an automatic offsetting entry or transfer posting when concluding a VAT group or standalone declaration. This is also pointed out in a notification in the VAT@GTC: "There are negative values in fields 029a, which are automatically transferred when the declaration is closed. Please check the correctness of these changes after completion of the declaration." When the declarations are reopened, all transfers are deleted again, so that the transfers can always be made on the basis of the final status of the declaration.
Good to know
This function is not available in manual standalones. Here, the values must be entered correctly directly. As a general rule, AMANA recommends always creating the declaration with tax code mappings, even if the values cannot be uploaded automatically.
As a general rule, negative input tax amounts can be entered in field 067 and negative tax amounts in field 090. Assessment bases that lead to a negative value should not be taken into account in the declaration. The problem with this is that they were taken into account at the time. Therefore, negative entries must be counter-posted so that the sum of the field is 0. As soon as a negative tax value exists, this must also be set to 0 in the original field and additionally entered in field 067 or 090. Three steps are used for the transfer posting:
Step 1: Set relevant field to 0,00€.
The field in which the negative value occurs must always be set to 0.00€.
Step 2: Has the entry been taken into account in other fields?
There are some matters in the declaration that must be taken into account in several fields. If the field is a matter that is also included in other fields, the same value that was offset in the first step must also be offset in the other field. There are three cases here:
- The value of this field is always taken into account in field 000 or field 001: Since field 001 is generally irrelevant for fee changes, the offsetting entry is also entered in field 000 in this case.
- The value of the field is also taken into account in field 070: The VAT@GTC automatically calculates this field as a total, so no explicit offsetting entry is necessary here.
- The value of the field does not affect any other field: In this case, this step is skipped.
Good to know
Automatically calculated total fields without a field ID are not meant here.
Step 3: Is there a tax to transfer?
If the field is or has a tax field, the value in the declaration must also be transferred to one of the fields where negative values are allowed so that the calculated tax does not change. There are 3 possibilities:
- Negative output tax is transferred negatively to field 090.
- Negative input tax is transferred positively to field 067 (the sum of the input tax is calculated negatively).
- Negative, non-deductible input tax (field 062) is transferred negatively to field 067.
These steps result in 8 different cases that are dealt with:
Case | Set the field to 0,00€ | Has the entry been taken into account in other fields? | Is there a tax to transfer? |
---|---|---|---|
Case 1: Tax-exempt Tax assessment bases | Yes | Is additionally counterposted in field 000. | No |
Case 2: Assessment bases to be taxed (022-009) | Yes | Is additionally counterposted in field 000. | Transfer of tax to field 090 |
Case 3: Further to be taxed (056-032) | Yes | No | Transfer of tax to field 090 |
Case 4: Tax-exempt intra-community acquisitions (071) | Yes | Is calculated correctly in 070 as a total without an offsetting entry. | No |
Case 5: Intra-community acquisitions to be taxed (072-010) | Yes | Is calculated correctly in 070 as a total without an offsetting entry. | Transfer of tax to field 090 |
Case 6: Non-taxable acquisitions (076, 077) | Yes | No | No |
Case 7: Input Tax (060-064) | Yes | No | (Positive) Transfer of input tax to field 067 |
Case 8: Not deductible input Tax (062) | Yes | No | (Negative) Transfer of input tax to field 067 |
Annual Declaration
The transfer of the preliminary declaration values to the annual declaration is done via mappings and cannot simply be added up. One of the reasons for this is that fee changes would otherwise not be taken into account.
Mainfield mapping
In the case of purely manual declarations, the transfer to the annual declaration takes place via a main field mapping. Almost all fields of the preliminary declaration are already stored in the standard system. Only fields 067 and 090 are not transferred to the annual return, as transfers due to changes in remuneration must be considered anew in the annual return. Therefore, other fields may still have to be adjusted after the transfer due to fee changes. AMANA therefore always recommends using tax codes even for manual declarations.
Tax code mapping
If tax codes are used, please note that the complete tax code mapping must also be available in the annual return, as the tax codes from the advance return are first added up and then assigned to the fields again via the mapping in the annual return. Transfer postings from fee changes are not transferred to the annual return, since fee changes are considered for the whole year in the annual return. If negative values from fee changes still remain from the cumulation of the tax codes in the annual declaration, they are also reposted accordingly in the annual declaration when the declaration is closed.
Number of companies
In the annual return, the total of all lower-level companies is also automatically determined and transmitted. In order for this figure to be calculated correctly, it is important that all existing companies in the VAT group are created as Representative/consolidated VAT group member or Vat group member. If a company has several company codes, these must also always be created as companie-subdivision, otherwise they would be counted.
Corrections
A correction of the VAT return in Austria can be submitted electronically once. The correction is made by submitting a new complete advance return for tax on sales/purchases.
If further corrections become necessary after the first correction, these can no longer be sent electronically via the interfaces, but must be submitted by post.
Reconciliations
In addition to the reconciliations available in each country (1,3,4,5,6,7,8,10), the following reconciliations can be run for Austria:
- Reconciliation 2: Compares code number 095 with the tax payable account from RFBILA00.
- Reconciliation 12: Reconciles reverse charge matters. The output tax code numbers 057, 048, 044 and 032 are compared with the corresponding input tax code numbers 066, 082, 087 and 089.
- Reconciliation 13: Reconciles intra-Community acquisitions. The output tax code numbers 072, 073, 008, 088 and 010 are compared with the corresponding input tax code number 065.
Sending the declaration
Requirements
The VAT return can be sent to FinanzOnline directly from the VAT@GTC.
Good to know
In order to be able to create a VAT return, a tax number must be entered in addition to the regular mandatory fields. The tax number must have nine digits and is made up of the two digits of the tax office number and your own tax number. In VAT@GTC, spaces and slashes must be omitted, the interface expects only the nine digits.
In order for a user to be able to submit a declaration to FinanzOnline, he or she needs an access from the Austrian tax office. This access requires activation for the web service in FinanzOnline. Such access with web service activation must be stored in VAT@GTC in the dialogue [Settings → User credentials] for each user who is to submit a report. For this purpose, an access date with the category REST-Service must be created:
Einstellung | Bedeutung |
---|---|
ID | The ID of the User credential. |
User-ID | The ID of the VAT@GTC user. |
Login | The Login of the VAT@GTC user. |
User name | The user name of the personal or technical FinanzOnline access. |
Password | The password of the personal or technical FinanzOnline access. |
Category | REST service must be specified here. |
Company transfer ID | The company transfer ID of the FinanzOnline company account. If a user looks after companies in different company accounts, they will therefore also need several entries for user credentials. |
Connection parameter | The interface to FinanzOnline, which is configured in the dialogue [Settings → Connection parameters]. |
Companies | One or more companies for which this access is valid can be stored here. Each company can be stored in a maximum of one FinanzOnline account per user. |
Transmission Process
When the declaration is sent, unlike in Germany, there is only a technical response stating whether the declaration has been received. However, this does not confirm whether the declaration is actually accepted by FinanzOnline. Only later does the tax office check whether the transmission is valid. As soon as this process is completed, a protocol is created by FinanzOnline. This protocol can be retrieved via the button [Retrieve protocols]. It may take several hours until the protocols are available.
In this protocol, it is finally stated whether the declaration was accepted by FinanzOnline.
Good to know
There are individual fields in the test transmission that are not fully checked. The tax number, for example, is only checked during the test transmission to see whether it exists and whether it consists of 9 digits. Whether it is an existing tax number is not checked during the test transmission. Therefore, the productive transmission is not necessarily successful if the test transmission was successful.
For the productive transmission, this means that the status of the declaration is initially set to [In transmission] when the transmission is carried out. If there are technical problems with the transmission so that the declaration is not received by FinanzOnline, the status remains closed and the transmission can be carried out again after these problems have been solved.
Once the status of the declaration is [In transmission], it can only be changed again with the protocol retrieval. When the production protocol has been successfully retrieved, there are two possibilities:
- The declaration is valid and has been accepted by FinanzOnline. In this case, the status of the declaration changes to [Sent].
- The declaration is not valid and cannot be accepted; the reason for this is stated in the protocol. The status of the declaration is set to [Send Error]. A correspondingly authorised user must now set the status of the company back to closed or open. The error in the declaration can then be checked and corrected. Afterwards, the sending process can be started again.
Good to know
Since the original declaration is not considered to have been submitted if the protocol reports back that there is still an error, the retransmission is not a correction.
Since the FinanzOnline protocol does not contain the transmitted declaration, a PDF export of the declaration is automatically created in VAT@GTC for more precise tracking and documentation and included in the document list of the [Send declaration] dialogue. This PDF is assigned a Transfer ID, which is also assigned to the transmission. Based on this, a PDF of the declaration can be assigned to the corresponding protocol of FinanzOnline. As soon as the protocol is retrieved, it can be found grouped with the PDF of the declaration in the document list. In this way, different tests or productive transmissions of a company can be distinguished from each other.