| Field |
Data format |
Comments |
| Creditor reference |
Character |
This is the same reference as shown in the standing data specification. See note below1 regarding inclusion of a Site ID. |
| Site ID |
Character |
If trade creditors can have more than one address these should be separately identifiable via the Site ID1. |
| Suppliers invoice number |
Character |
This should be the reference shown on the supplier's invoice - usually a number but may have alpha prefixes or suffixes. |
| Internal/system invoice number |
Character |
Most systems generate a unique, sequential transaction number so all invoices, credit notes, payments, etc. can be separately identifiable. |
| Invoice date |
Date |
This should be the date on the invoice, but could be the date of input if the invoice date is not available. |
| Due date |
Date |
|
| Payment date |
Date |
If the invoice has not been paid then leave blank. If your system enters a default date and therefore you can't leave it blank, please tell us what the default date is. |
| Total invoice amount |
Numeric |
The 'total invoice amount' is inclusive of VAT, less any discount. However, some systems hold VAT exclusive amounts, with the VAT figure held separately. In this case these figures should be added together to produce the 'total invoice amount'. |
| VAT amount |
Numeric |
This should be separately identifiable for each invoice but could be nil if invoice is zero rated, exempt or outside the scope of VAT. |
| Method of payment |
Character |
E.g.: BACS, cheque, cash, payable order etc. If codes are used, a 'key' to the codes should be sent with the data submission. |
| Payment reference number |
Character |
This field should contain the cheque, payable order (PO) or BACS reference number by which the invoice was paid. This means that invoices that have been paid together would have the same cheque/PO/BACS number. |
| Remarks |
Character |
This filed can be used as a free text field to include information that may assist you when investigating matches. |