stuzza (51)
Gutschriftstruncation
Thus the payment reference is hedged with a check digit calculated in accord with ISO 7064. This check digit facilitates the automatic capture and ensures higher detection rates in the processing. Hence the automatic assigning and entering of claims achieves a significantly higher rate.
For that purpose is an Excel-Sheet available, which illustrates the calculation of check digits in the "Truncationsverfahren" and also suits the creation of small amounts of check digits.
Since the 1st January 2009 the possibility for a "Gutschriftstruncation" with the was created. It concerns an additional check digit on the "Zahlungsanweisung". This supplementary check digit ensures the correct processing of the reference on the receipt by the system. The payment reference solely consists of 35 digits.
Tax payments
The tax payments were redeveloped and designed especially for transactions to the revenue office. Multiple types of taxes may be settled up simultaneously via receipt.
A standardised payment reference is necessary for tax payments/post bar payments respectively EACT. Further informations on this subject are available here, where we provide corresponding tools with which the payment reference can be calculated automatically.
Printing Forms Order
Here you can order important informations and printing forms for the creation of payment transactions forms which follow the standardised criteria.
WORKSHOP: XML in payment transactions
EACT-Purpose
Creating and testing the special purpose according to EACT-Format
IBAN-CHECK
The IBAN consists of the ISO-country code, a two-digit check digit, bank informations and the account number. The length of the IBAN can contain up to 34 digits because of country-specific conditions. Austrian IBANs consist of 20 digits.
With the Check-script you can check an IBAN on its formal correctness.
|
|
|
|
Format Descritption IBANService
This is how your request should look like:
| Line | Content |
| 1 | REQS;1234567890123456;USRT;2012-01-07;10:11:12;1-1 |
| 2 | 12345;12345678901;;;; |
| 3 | 67890;123456;;;; |
| 4 | 12345;678901;;;; |
| 5 | 54321;123456701;;;; |
| ... | ... |
The response looks like this:
| Line | Content |
| 1 | RTRN;1234567890123456;USRT;2012-01-09;14:15:16;1-1 |
| 2 | 67890;123456;ABCDATWW;AT126789012345678901;;CMPT |
| 3 | 12345;12345678901;ABCDATWW;AT121234512345678901;54321;CMPT |
| 4 | 54321;123456701;;;;AGNX |
| 5 | 12345;678901;;;;ACCL |
| ... | ... |
Hint (when sending a request):
The first line contains 6 fields in the predefined order:
| "REQS" | for Request |
| Bank code/ Account |
exactly 16 digits, numerical, of the requesting account holder |
| "USRT" | for unsorted accounts |
| Date | of the creation of the request in the form YYYY-MM-DD |
| Time | of the creation of the request in the form hh:mm:ss |
| Numbering | of the request in the form n-m meaning "n"th request of "m" requests thereby large stocks can be divided or multiple requests can be created range from 1-1 to 999-999 |
The second line contains 6 fields in the predefined order:
| Bank code |
| Account number |
| 4 blank fields as a placeholder for the response |
Permitted separators are semicolon, comma or tabulator
For Response, please note:
The first line contains 6 boxes in the prescribed order:
| "RTRN" | for Return |
| Bank code/ Account |
exactly 16 digits, numerical as in the request |
| "USRT" | for unsorted accounts, "SORT" for accounts sorted by bank code |
| Date | of the creation of the response in the form YYYY-MM-DD |
| Time | of the creation of the response in the form hh:mm:ss |
| Numbering | in the form n-m (as received in request) |
The second line contains 6 fields in the predefined order:
| Bank code | as in the request |
| Account number | as in the request |
| For CMPT related BIC | or blank |
| For CMPT related IBAN | or blank |
| Optional | the responding office, bank code or BIC or blank |
| Status code | CMPT, AGNX, NDAV, ACNX, ACCL, OERR |
Meaning of the codes:
| CMPT | complete (=OK) IBAN/BIC attached |
| AGNX | agent not existing meaning the IBANService has not registered the bank code and does not know which bank is responsible for the response |
| NDAV | no data available meaning the IBANService registered the bank code indeed, but no informations of this bank code can be delivered |
| ACNX | account not existing meaning the bank does not manage an account with this number |
| ACCL | account closed meaning the bank has already closed the account |
| OERR | other error meaning no otherwise relatable error occured at the investigation |
IBAN and BIC
By IBAN and BIC bank connections are unitarily indicated for SEPA-transactions
The unitary format offers a cross-border possibility to check accounting connections for formal correctness already at the capture. Thereby typing errors of all kinds are detected reliably.
IBAN and BIC must be applied in SEPA payment transactions
Hence the EPC(EuropeanPaymentsCouncil) imposed the usage of this account representation for all SEPA payment transactions on using of fundamental payment methods.
IBAN and BIC must not be "calculated" by oneself
Although offers appear in all kinds by now and existing accounting connections in the form account number / bank code must be transferred into the representation IBAN / BIC, the sole valid information concerning this are reserved for the bank in charge of the account and the account owner. On one hand the bank codes, used in the IBAN, differ partially, on the other hand not all BICs of a bank can be used for payment transactions.
