March 1 and 2 - Service outage notice
There will be an intervention that may affect this service on March 1st and 2nd, 2025. If you are unable to access, please try again after 10pm on March 2nd.
More information at:
Scheduled intervention on March 1 and 2 that involves a service outage AOC
If the reason for rejection does not appear in the list in this article, then it is an error reported by the recipient (Commercial rejection). For any questions about a commercial rejection, you should contact the organization to which you sent the invoice.
Below are the most common rejection errors , which can be of two types:
- Rejection errors for commercial reasons are those defined by the receiving organization of the invoice; these error codes and/or literals are unrelated to e-FACT, for this reason, these types of errors are not described in this FAQ. You should contact the receiving organization in case of doubt.
- Rejection errors for technical reasons are those that the tool automatically generates when performing certain internal validations.
Any error that requires correction of the invoice must be corrected by regenerating the XML and signing it again. If a change is made to the content of an XML that has been signed, the invoice signature will become invalid.
Below we describe the most common technical rejection errors:
FORMAT ERROR
| Code | Error literal | What does it mean? | How to solve it? |
|---|---|---|---|
| No code | The invoice is not in the correct format. | This error appears when an invoice is uploaded to the delivery mailbox and it does not respect the invoice format. |
Validate the invoice , check if the format is correct and correct any possible errors. The most common reasons for format errors are as follows: – In the PersonTypeCode field you are putting a “J” for legal person and therefore the CIF of a legal person must be put, if you put “F” for physical person you must put the NIF of a natural person. – The header does not contain the expected format. Every invoice must begin with: – The format of one of the identity documents (issuer NIF/CIF, recipient CIF, third party CIF, etc.) is incorrect. It cannot contain any spaces or dashes. |
| HF01 | Incorrect filename format | The file format does not follow the guidelines indicated in the integration guide. | The format indicated in the integration guide must be reviewed and corrected. |
| HF08 | Schema validation error | The submitted invoice schema has not passed syntactic validation and/or the validation of the published extensions has not passed . | The invoice must be generated in invoice format 3.2 and 3.2.1. |
REGISTRATION ERROR
| Code | Error literal | What does it mean? | How to solve it? |
|---|---|---|---|
| HRE1 |
Error registering document Registration error in MUX |
The invoice could not be registered correctly because there is an element that is not reported correctly. |
Validate the invoice XML, if it passes validation try sending it again. If the error persists, talk to the destination organization to find out if they have any errors in their registration system. |
| EV02 | Duplicate invoice | The invoice has already been sent. |
Verify that the invoice has not been sent previously. You can check the status of the invoice in the Delivery Box. |
| DF01 | The receiving body has rejected the invoice manually | Error detected by the body receiving the invoice | You must contact the invoice recipient to obtain more details about the commercial rejection of the invoice. |
| HS01 | Unknown broadcasting platform code | For example, if the invoice is delivered from an issuing platform not affiliated with the e-FACT service | See platforms affiliated with the e-FACT service : Create and send invoices |
| HR01 | Unknown receiving platform code | Unknown invoice receiving platform code. That is, it was sent to a platform code that does not exist in e-FACT | The recipient platform code of the invoice is unknown. You must review or confirm the receiver code with the recipient. |
| HS02 | Broadcast platform deactivated | The broadcasting platform is not properly configured. | You need to review the configuration of the sending platform and if you believe that the configuration is correct, send us the error, indicating the platform from which it is sent and attaching the invoice xml and the error xml. |
| EG01 |
Generic error in the invoice reception process | There was an error loading your invoice. | Reload the invoice after a few minutes. If the error persists, please send us the error by attaching the invoice xml. |
SIGNATURE ERROR
| Code | Error literal | What does it mean? | How to solve it? |
|---|---|---|---|
| HF04 | The file does not contain an electronic signature. |
An attempt was made to send unsigned XML to the platform. |
Must sign the XML to respect the invoice format . For more information, see How to resolve signature errors. |
| HV01 | Error verifying signature/certificate |
The invoice has not passed validation of the issuer's digital certificate (expired or unrecognized certificate) or the electronic signature of the invoice could not be validated (its format is incorrect). |
Check that the SigningTime field in the XML contains the invoice signing time without any numbers or strange characters. If you see, for example, a +2 or a Z, you must re-sign the invoice and send it again. If there is nothing that alters this field, you must review the certificate used to sign the invoice through Signasuite. For more information, see How to resolve signature errors. |
| HV02 | Signature/certificate validation failed. | The number of retries established to validate the signature and certificate of an invoice has been exceeded , and therefore, the invoice will be rejected. |
You need to resend the invoice. If the problem persists , see How to resolve signature errors. |
CONTENT ERROR
| Code | Literal | What does it mean? | How to solve it? |
|---|---|---|---|
| HR11 | Recipient Company Name not indicated or reported | It is necessary to indicate the corporate name within XML. |
This point must be corrected and the invoice resented. |
| HD01 | Error sending message to destination platform | An attempt is being made to send an attachment for which we do not have a previous invoice associated. |
The invoice for the associated attachment must be sent in advance. |
| HS09 | NIF issuer not indicated in document | The invoice does not contain the issuer's NIF. |
Check that the XML of the invoice contains this data (issuer's NIF) |
| HR09 | Receiver NIF not indicated in document | The invoice does not contain the recipient's NIF. | Check that the XML of the invoice contains this data (recipient's NIF) |
| HR10 | Recipient NIF indicated on invoice does not match destination entity | The invoice does not correctly report the recipient's NIF | You must review the NIF indicated in the invoice XML. |
| HR04 | Received file content not supported by destination platform | Delivery of an invoice with an unaccepted version of the facturae format. For example, invoice generated with version 3.oo or 3.1. | The invoice must be generated in Invoice format 3.2 and 3.2.1 . |
| HF03 | Received file content not supported by Hub | The file content is incorrect mainly because it is not an invoice format. | The invoice must be generated in Invoice format 3.2 and 3.2.1 . |
| HF07 | Only Invoices with a single invoice are supported. | The . XML file contains more than one invoice and only invoice files with a single invoice are supported. | The XML must be regenerated into a single invoice. |
ERROR WITH ADDRESS CODE
| Code | Literal | What does it mean? | How to solve it? |
|---|---|---|---|
| HS05 | Incorrect sender address code (invalid check digit) | The issuing platform has incorrectly reported the check digit (last number) of the issuer's addressing code (issuer identifier) |
The format indicated in the integration guide must be reviewed and corrected. |
| HR05 | Incorrect receiver addressing code (invalid check digit) | The check digit (last number) of the receiver addressing code (receiver identifier) is not correct, according to the format indicated in the integration guide. |
The format indicated in the integration guide must be reviewed and corrected. |
| HR08 | Receiver address code is not an AAPP | The recipient's addressing code (recipient identifier) does not correspond to a public body |
The format indicated in the integration guide must be reviewed and corrected. |
| HR06 | Receiver addressing code does not exist. | The receiver addressing code (receiver identifier) does not exist (see integration guide ). |
See the integration guide and if you think it is correct, send us the error, attaching the invoice xml and the error xml : |
| HS06 | There is no previous ref. indicated in the attachment. | The attachment is rejected because a registered invoice with the same reference as the attachment was not found. |
See the “Management of attached documents” section of the integration guide. |
RCF ERROR HF09
Below are defined the new rejection codes added due to the new validations incorporated by the necessary adaptations of e-FACT to comply with the requirements of the PGE as established in Order HAP/1650/2015, of July 31, which modifies Order HAP/492/2014, of March 27, which regulates the functional and technical requirements of the accounting register of invoices of entities within the scope of Law 25/2013, of December 27, on the promotion of electronic invoices and the creation of the accounting register of invoices in the public sector, and Order HAP/1074/2014, of June 24, which regulates the technical and functional conditions that the general point of entry for electronic invoices must meet : https://www.boe.es/diario_boe/txt.php?id=BOE-A-2015-8844
How are RCF rejects returned to the PGE?
When an invoice is rejected for not complying with the validation rules, all these errors have been grouped in the code = HF09 and the description includes the specific error code and its description. All errors detected are returned in the following format:
- “Error code: Description | error code: Description”
For example, in an invoice with validation errors detected RCF05002 and RCF05004, the following would be returned as a rejection comment:
- RCF05002: Issuer: The NIF does not comply with the rules and criteria for its formation. Rule number 5b of Annex II of Order HAP / 1650/2015 is not complied with | RCF05004: Issuer: The name and first surname are mandatory. Rule number 5d of Annex II of Order HAP / 1650/2015 is not complied with |
Description of validation errors
| Error | Code | Error description | Field that needs to be corrected in the invoice XML and/or how to fix it? |
|---|---|---|---|
|
HF09 |
RCF03001 | "The invoice number is mandatory. Rule 3a of Annex II of Order HAP/1650/2015 is not complied with " |
3.1.1.1.InvoiceNumber Please enter an invoice number in this field. |
| RCF04001 | "Rectification invoice with rectification criterion other than 01,02,03,04. Rule 4a of annex II of Order HAP/1650/2015 is not complied with " |
3.1.1.5.6.CorrectionMethod Indicate one of the possible rectification criteria: 01,02,03,04 |
|
| RCF04002 | For rectification invoices with rectification criterion 01 or 02, the invoice number of the issuing issuer is mandatory. Rule 4b of Annex II of Order HAP/1650/2015 is not complied with |
3.1.1.5.1.InvoiceNumber Indicate the invoice number of the issuer that is rectifying, in this field. |
|
| RCF05001 | Issuer: The code of type of person, physical \"F\" or legal \"J\" is mandatory. Rule 5a of annex II of Order HAP/1650/2015 is not complied with |
(2.1.1.1.PersonTypeCode) Indicate code “F” or “J” in this field. |
|
| RCF05002 | Issuer: The NIF does not conform to the rules and criteria of its formation. Rule 5b of annex II of Order HAP/1650/2015 is not complied with |
2.1.1.3.TaxIdentificationNumber Amend taking into account this criterion: If the first two characters of the NIF are letters it will be assumed that they are equivalent to the country, and the rest to the NIF. In another case, the code indicated will be equivalent to the NIF and it is assumed that the code is Spain. |
|
| RCF05003 | Issuer: The country code (two first characters of the NIF when they are letters) when it exists, will be adjusted to what is established in the Invoice scheme itself. Rule 5c of Annex II of Order HAP/1650/2015 is not complied with | 2.1.1.3.TaxIdentificationNumber | |
| RCF05004 | Issuer: The number and first name are mandatory in the case of a natural person. Rule 5d of annex II of Order HAP/1650/2015 is not complied with |
2.1.4.2.1.Name 2.1.4.2.2.FirstSurname Fill in these fields |
|
| RCF05005 | Issuer: The company name is mandatory in the case of a legal entity. Rule 5e of annex II of Order HAP/1650/2015 is not complied with |
2.1.4.1.1.CorporateName Fill in this field |
|
| RCF05006 | Assignee: The code of type of person, physical \"F\" or legal \"J\" is mandatory. Rule 5a of annex II of Order HAP/1650/2015 is not complied with |
1.6.1.1.1.PersonTypeCode Indicate code “F” or “J” in this field. |
|
| RCF05007 | Assignee: The NIF does not conform to the rules and criteria of its formation. Rule 5b of annex II of Order HAP/1650/2015 is not complied with |
1.6.1.1.3.TaxIdentificationNumber Amend taking into account this criterion: If the first two characters of the NIF are letters it will be assumed that they are equivalent to the country, and the rest to the NIF. In another case, the code indicated will be equivalent to the NIF and it is assumed that the code is Spain. |
|
| RCF05008 | Assignee: The country code (two first characters of the NIF when they are letters) when it exists, will be adjusted to what is established in the Invoice scheme itself. Rule 5c of Annex II of Order HAP/1650/2015 is not complied with | 1.6.1.1.3.TaxIdentificationNumber | |
| RCF05009 | Transferee: The number and first name are mandatory. Rule 5d of annex II of Order HAP/1650/2015 is not complied with |
1.6.1.2.2.1.Name 1.6.1.2.2.2.FirstSurname Fill in these fields |
|
| RCF05010 | Assignee: The company name is mandatory. Rule 5e of Annex II of Order HAP/1650/2015 is not complied with |
1.6.1.2.1.1.CorporateName Fill in this field |
|
| RCF06001 | In the invoices issued in euros, some of the line amounts have more than two decimal places or are not numeric. Rule 6a of Annex II of Order HAP/1650/2015 is not complied with |
The amount fields that are validated are as follows: 3.1.6.1.17. TotalCost 3.1.6.1.18.1.3. DiscountAmount 3.1.6.1.19.1.3. ChargeAmount 3.1.6.1.21.1.3.1. TaxableBase.TotalAmount 3.1.6.1.21.1.4.1. TaxAmount.TotalAmount 3.1.6.1.22.1.4.1. TaxAmount.TotalAmount NOTE : Verify that the fields do not contain spaces after the amount. |
|
| RCF06002 | In invoices issued in euros, the total cost of each line must be equal to the product of the number of units by the unit price rounded with the common method of rounding to two decimal places. Rule 6a of annex II of Order HAP/1650/2015 is not complied with |
If there are more than two decimal places, the ones after the second must be zero: 3.1.6.1.17.TotalCost = RoundingA2decimals (3.1.6.1.14.Quantity*3.1.6.1.16.UnitPriceWithoutTax) |
|
| RCF06003 | In invoices issued in euros, the gross amount of each line must be the sum of the total cost plus the sum of surcharges minus the sum of discounts. Rule 6a of annex II of Order HAP/1650/2015 is not complied with |
Check that: 3.1.6.1.20.GrossAmount is equal to 3.1.6.1.17.TotalCost minus SUM(3.1.6.1.18.1.3.DiscountAmount) plus SUM(3.1.6.1.19.1.3.ChargeAmount) |
|
| RCF06004 | In the invoices issued in euros, any of the amounts at invoice level, except the tax rates or the percentages to be applied, have more than two decimal places or are not numerical. Rule 6b of Annex II of Order HAP/1650/2015 is not complied with |
The amount fields that are validated are as follows: 3.1.5.1. TotalGrossAmount 3.1.5.3.1.3. ChargeAmount 3.1.5.7. TotalTaxOutputs 3.1.5.10.1.3. SubsidyAmount 3.1.5.11.1.2. PaymentOnAccountAmount 3.1.5.12.1.6. ReimbursableExpensesAmount 3.1.5.13. TotalFinancialExpenses 3.1.5.15. TotalPaymentsOnAccount 3.1.5.16.3. WithholdingAmount 3.1.5.18. Total ReimbursableExpenses 3.1.3.1.3.1. TaxableBase.TotalAmount 3.1.3.1.5.1. SpecialTaxableBase.TotalAmount 3.1.3.1.6.1. SpecialTaxAmount.TotalA 3.1.3.1.8.1. EquivalenceSurchargeAmount.TotalAmount 3.1.4.1.3.1. TaxableBase.TotalAmount 3.1.4.1.4.1 TaxAmount.TotalAmount NOTE : Verify that the fields do not contain spaces after the amount. |
|
| RCF06005 | In invoices issued in euros, the total gross amount of the invoice must be the sum of the gross amounts of the lines. Rule 6b of annex II of Order HAP/1650/2015 is not complied with | 3.1.5.1.TotalGrossAmount = SUM(3.1.6.1.20.GrossAmount of the lines) | |
| RCF07002 | The date of issue of the invoice is mandatory and must be a valid date. Rule 7a of annex II of Order HAP/1650/2015 is not complied with |
3.1.2.1.Issue Date Indicates a date before or equal to the current date and greater than or equal to the invoice issue date. |
|
| RCF09002 | There are invoice lines without content in the description. Rule 9b of annex II of Order HAP/1650/2015 is not complied with |
3.1.6.1.13.ItemDescription Check that there are no blank rows in this field. |
|
| RCF01001 | The invoice does not comply with the "Facturae" XSD scheme of the corresponding version (3.2 or 3.2.1). Rule 1 of annex II of Order HAP/1650/2015 has been breached |
Validate that the invoice format complies with the “Facturae” schema: |
|
| RCF02001 | Invalid signature: Certificate currently expired in a non-long-lived signature. Rule 2 of annex II of Order HAP/1650/2015 is breached |
Validates that the signature conforms to the signature policy in force associated with the “Facturae” format: |
|
| RCF02002 | Invalid signature: Certificate currently revoked in a non-long-lived signature. Rule 2 of annex II of Order HAP/1650/2015 is breached |
Validates that the signature conforms to the signature policy in force associated with the “Facturae” format: |
|
| RCF02003 | Invalid signature: Invalid certificate. Rule 2 of annex II of Order HAP/1650/2015 is breached |
Validates that the signature conforms to the signature policy in force associated with the “Facturae” format: |
|
| RCF02004 | Invalid signature: Untrusted certificate. Rule 2 of annex II of Order HAP/1650/2015 is breached |
Validates that the signature conforms to the signature policy in force associated with the “Facturae” format: |
|
| RCF02005 | Invalid signature: Integrity error. Rule 2 of annex II of Order HAP/1650/2015 is breached |
Validates that the signature conforms to the signature policy in force associated with the “Facturae” format: |
|
| RCF02006 | Invalid signature: Invalid signature format. Rule 2 of annex II of Order HAP/1650/2015 is breached |
Validates that the signature conforms to the signature policy in force associated with the “Facturae” format: |
|
| RCF02010 | The invoice does not contain signatures: Rule 2 of Annex II of Order HAP/1650/2015 is not complied with |
Validates that the signature conforms to the signature policy in force associated with the “Facturae” format: |
|
| RCF09001 | The registration number assigned at the general entry point for electronic invoices is mandatory. Rule 9a of Annex II of Order HAP/1650/2015 is not complied with | ||
| RCF07001 | The date of entry in the administrative register is mandatory, it must be valid, prior to or equal to the current date and greater than or equal to the date of issuance of the invoice. Rule 7a of annex II of Order HAP/1650/2015 is not complied with | 3.1.2.1.IssueDate |