Creditors data specifications
- Please note, these data specifications are only applicable to private sector bodies.
- In order to for creditors screening to be undertaken you will be required to submit a creditors standing data file and a creditors history data file. Data specifications for both of these files are shown below.
- Data should only be submitted via the Data File Upload (DFU) facility. This is now the only acceptable method to supply data. If another submission method is used our policy is to inform the Director of Finance that data has been put at risk unnecessarily.
- Standing data should be current at the date of extraction and should exclude dormant or suspended creditors.
- It is essential that the guidance provided is referred to in conjunction with this data specification.
Trade creditors standing data
Requirements:
- Standing data should be current at the date of extraction and should exclude dormant or suspended creditors.
| Field name | Data format | Comments |
|---|---|---|
| Creditor reference | character | Revised: This is the unique identifier for an individual creditor. This can be in the form of a numeric or alpha numeric string. |
| Site ID | character | If creditors can have more than one address these should be separately identifiable via this Site ID1 |
| Creditor name | character | |
| Address 1 | character | If the address is held in a single field, use the Address 1 field. |
| Address 2 | character | |
| Address 3 | character | |
| Address 4 | character | |
| Postcode | character | |
| Telephone number | character | This may or may not have the area/STD code. It should be output as a character field so the leading zeros are not lost. |
| VAT registration number | character | This should be in the form of a 9 figure number, but should not be numeric as this could lose any leading zeros. |
| Bank sort code | character | 6 numeric characters in groups of 2 which may be separated by hyphens, eg, 20-45-23. |
| Bank account number | character | Usually 8 numeric characters. |
| Building society roll number | character | Building societies have a roll number where payments are disbursed to after being paid into a single account. This should be blank for normal bank accounts. |
| Creditor type2 | character | For example, ’1 = trade creditor,2 =payroll, 3 = factor, 4 = grants, 5 = temporary/one-off, etc. Then provide a key to the codes used. If this type of identifier is not available from the system it would be to your advantage to populate this field to enable you to filter the output more easily and focus resources on what you may deem to be the most worthwhile matches. |
Trade creditor payments history data
Requirements:
- Trade creditors payments history data should cover at least the last three financial years.
| Field name | Data format | Comments |
|---|---|---|
| Creditor reference | Character | This is the same reference as shown in the standing data specification. See note below_ regarding inclusion of a Site ID. |
| Site ID | Character | If creditors can have more than one address these should be separately identifiable via this Site ID1 |
| Suppliers invoice number | Character | This should be the reference shown on the suppliers 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. |
| AdInvoice 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 | This may be automatically generated by the system according to the conditions attached to each creditor. |
| Payment date | Date | If the invoice has not been paid then leave blank. If your system enters a default date and therefore you cant 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. |
| 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. |
1 If a Site ID is provided in the standing data file, it should also be included on the payments history file so that there is a unique linking field between the two datasets. This will make it possible to establish cumulative payments to individual trade creditor sites (which are attached to the standing data) and to attach the trade creditor names to each transaction on the payments history file.
2 This field only needs to be populated if you are unable to submit trade creditors data on its own.