Introduction

Spain’s SII (Suministro Inmediato de Información) requires companies to submit invoice records to the AEAT tax authority within 4 days of posting (8 days for self-invoices). Beyond the submission deadline, Law 11/2021 of 9 July 2021 — on measures to prevent and combat tax fraud — introduced Article 29.2.j) of the General Tax Law, which obliges all accounting and invoicing systems to guarantee the integrity, preservation, accessibility, legibility, traceability, and unalterability of billing records, preventing interpolations, omissions, or alterations without a proper audit trail.

Meeting this obligation requires more than just sending the XML to the Tax Agency. You also need to verify that the records on both sides — your SAP system and the Tax Agency portal — remain consistent over time. There are three distinct layers of consistency to consider:

Layer	When it runs	Who checks	What it catches
Vaidations	At the moment of reception by the Tax Agency	Tax Agency (response codes)	Fiscal correctness of the data
SII application checks	During the SII eDocument creation or XML submission process	SAP (ESSII_EDOCCREATE / ESSII_EDOCLIST)	Configuration or data errors that prevent list submission
Consistency Checks	As a separate scheduled process	SAP Consistency Checks framework	Discrepancies between the records already in SAP and those already at the AEAT.

This blog focuses on the third layer — the Electronic Document Consistency Checks framework in SAP S/4HANA, Apps “Check Electronic Document Consistency” (F7494),  “Resolve electronic Document Inconsistencies” (F7043), “Schedule Jobs for Electronic Document Consistency” (F7494)  and  “Display Electronic Document Consistency Logs”  (F8173).

Inconsistencies at this layer are silent by default: the system keeps running, invoices keep posting, and SII submissions keep going out — but some documents are in the wrong state, missing from one side, or have content differences you are unaware of. Left undetected, these discrepancies surface during period-end reviews or AEAT audits at the worst possible moment.

Any company with a Spanish company code subject to SII — typically with an annual turnover above 6 million Euros, or voluntarily opted in — runs monthly or even daily SII reporting cycles. The Consistency Checks framework is relevant for all of them, but it is especially critical in the following situations:

• High-volume invoicing (retail, utilities, distribution) where communication timeouts between SAP and the AEAT are statistically inevitable.
• Companies that use both SAP and a non-SAP billing platform, where some invoices may have been submitted to the AEAT directly and have no eDocument counterpart in SAP.
• Companies that had to perform manual corrections directly on the AEAT portal (e.g., to deregister an invoice outside the normal SAP flow), leaving a content or status mismatch.

 

Inconsistency types

Not all inconsistencies look alike. The three layers introduced above each have a different failure signature:

Validation failures are returned by the AEAT as response codes when SAP submits a list. The Tax Agency's  official Validations and Errors document defines three categories: structural (the entire request is rejected), syntactic (the invoice is rejected), and business (the invoice is registered but marked with errors that must be corrected). Common examples:

• Error 3000 — Duplicate invoice. The Tax Agency already has a record for the same issuer NIF + invoice number + issue date combination. The most frequent error in practice.
• Error 1157 — Incomplete VAT breakdown. The <DesgloseFactura> block must include at least one of <InversionSujetoPasivo> or <DesgloseIVA>.
• Error 1166 — Invalid tax rate. The value in <TipoImpositivo> is not in the list of permitted values (common in Canary Islands IGIC scenarios).
• Error 1579 — <CuotaDeducible> on a non-Spanish DUA must be 0 when <TipoFactura> is F5.
• Error 1279 — <CuotaDeducible> not allowed on simplified invoice type F2.

SAP SII does not validate these business rules before submission and it is the customer’s responsibility to ensure data quality upstream.

SII Application failures surface during the SAP eDocument creation or list generation process (ESSII_EDOCCREATE / ESSII_EDOCLIST). A typical example is error EDOCUMENT_ES_SII 027 (“eDocument for source XXXX is not valid for lists”), which occurs when the Invoice ID is incomplete — a missing BP tax ID or invoice number field — and the eDocument ends up in NOT_VALID_FOR_BUND status. These errors are visible in the SII Cockpit (EDOC_COCKPIT) or in the “Manage Electronic Documents” App and are normally  resolved by fixing the underlying source data.

Consistency Checks — the focus of this blog — are different. After a successful submission, the Tax Agency and SAP records can gradually drift apart. None of these generate an active error during day-to-day operations; they only surface when you actively run the Consistency Checks process:

• eDocuments stuck in Registered with Errors or Missing Response in “Manage Electronic Documents” App or SII Cockpit even though the Tax Agency has long since accepted or deregistered the invoice.
• An invoice that appears on the Tax Agency portal under your tax ID but has no corresponding eDocument in SAP — perhaps entered manually during a system outage.
• An invoice SAP submitted successfully, but the Tax Agency portal shows Correcta while SAP still shows Rejected because the HTTP response was lost in transit.
• A reversal journal entry posted in SAP, but the corresponding deregistration eDocument was never submitted to the Tax Agency.
• A document whose field values (tax base, tax amount, reporting period) differ between the Tax Agency record and the SAP eDocument, caused by a manual edit on the Tax Agency portal after submission.

 

Consistency Checks and SII

SII is an asynchronous submission process. SAP sends an XML payload to the Tax Agency, and the Tax Agency responds asynchronously with an acceptance or rejection. This creates several known failure modes:

1. Lost response: SAP submits successfully and the Tax Agency registers the invoice, but the HTTP response never reaches SAP (network timeout, integration middleware restart). SAP records the eDocument as Missing Response or keeps it in Registered with Errors, while the Tax Agency side shows Correcta.
2. Wrong endpoint: The integration package SAP Document and Reporting Compliance: Electronic Tax Register Books for Spain was pointed at the Tax Agency test endpoint during testing and never updated. All submissions went to the sandbox; the production Tax Agency portal has no record of them.
3. Manual AEAT portal entry: An invoice was entered directly on the Tax Agency's portal — either during a system migration, a disaster recovery scenario, or because the customer wanted a correction that was not feasible in SAP at the time. The Tax Agency record exists; SAP has no matching eDocument.
4. Manual AEAT portal deregistration: An invoice was deregistered directly on the AEAT portal without going through SAP’s standard reversal flow (EDOC_DEREGISTER). SAP still shows the eDocument as Registered; the Tax Agency shows it as Anulada.
5. Content editing on the AEAT portal: The Tax Agency or the company manually adjusted a field value on the portal (e.g., correcting a NIF or a tax amount). The eDocument in SAP was never updated, creating a content mismatch.

The Consistency Checks framework is designed specifically to detect all these scenarios systematically, not just on demand.

 

Consistency checks process end-to-end

The end-to-end process runs in five steps. The first step is a one-time setup; the remaining four are part of the regular operational cycle. 

 

 

 

1. Configure the framework (one-time setup)

Before any check can run, you must activate the Consistency Checks framework for each company code. This is done through three Self-Service Configuration UI (SSCUI) activities in the Manage Your Solution app:

SSCUI 106403 — Enable Consistency Checks for Company Codes

 

This is the master switch. For each company code, you select:

• Consistency Scenario — the business process to cover
  • Spain SII Supplier Invoice
  • Spain SII Customer Invoice
• Comparison Type — which pair of documents to compare: eDocuments vs. the AEAT portal, or source documents (journal entries) vs. the eDocuments generated from them., such as:
  • Journal Entry vs. eDocument
  • SAP vs. Tax Authority
  • Reversal Journal Entry vs eDocument
  • Tax Authority vs. SAP

• Electronic Document Types — the specific document types to include in the checks according to the comparison type, such as:
  • SII Incoming Invoice
  • SII Outgoing Invoice
  • …
• Check Types — which checks to activate per document type, such as:
  • If document data is consistent
  • If document data is consistent 
  • If a journal entry exists
  • …

SSCUI 106684 — Assign Journal Entry Types to Comparison Types

Required when you activate the source-document comparison type (journal entry vs. eDocument). For each consistency scenario and comparison type, you assign which journal entry types (formerly accounting document types) should be included in the scope of the comparison.

 

SSCUI 106707 — Define Tolerance Limits for Amount Mismatch

Configures acceptable amount differences for the Content Check. A Content Mismatch is only flagged if the difference exceeds the defined threshold. Two tolerance types are available:

• Value — the absolute difference must exceed the fixed threshold (e.g., more than 0.01 EUR) to be flagged.
• Percentage — the difference must exceed the configured percentage; the lesser of the percentage-derived limit and the fixed limit is applied.

 

2. Retrieve the latest invoice records from the Tax Agency

Before running the consistency checks, your SAP system needs an up-to-date copy of what the Tax Agency has on record. Use the Process eDocument Inbound Messages app (or transaction EDOC_INBOUND_MSG) to pull the Tax Agency's invoice records into SAP. This is the data source that the comparison engine uses.

 

 

 

Normally this process should come together with “Schedule Job for document consistency”, however, you may schedule this step individually:  the Tax Agency data is the baseline for all comparisons.

 

3. Schedule the consistency check jobs

This app lets you configure and schedule automatic comparison runs for your company codes.

 

1. In the app, create a new job using the template “Automatic resolution of identified inconsistencies”. This template both detects and resolves inconsistencies that have a deterministic resolution (e.g., updating an eDocument process status to match the Tax Agency). For inconsistencies that require human interaction (e.g., content mismatches), it will detect and flag them but not auto-resolve.
2. Set the company codes and the SII scenarios (ESSIIOUT for customer invoices, ESSIIOUT for supplier invoices) you want to cover.
3. Configure a recurring schedule — daily or weekly depending on your volume.

After running, a log is visible:

The details are also visible: 

 

 

4.  Review inconsistencies in the Check app

This app shows all detected inconsistencies grouped by type. Use the filters to narrow down by company code, document type, or consistency result process.

The checks are organized in the following layers:

A) Consistency check between SAP system and Tax Agency:

• Existence Check
  • eDocument Missing for Tax Authority Document.  There is an invoice record in the tax agency without eDocument
  • Tax Authority Inv. Missing. The invoice records corresponding to existing eDocuments were not found in the Tax Agency portal.
• Status Checks:
  • Status Mismatch: Update Status. eDocument status to be updated keeping the Tax Agency document as a source of truth, in order to move towards a consistent result.
  • Status Mismatch: Complete eDocument. eDocument status to be marked as completed.
  • Status Mismatch: Other Actions. The system cannot determine what status prevail. Manual adjustment of the status required in either the eDocument or the Tax Agency invoice record.
• Content Checks:
  • Content Mismatch . There is an discrepancy  between  the invoice record in the tax agency and the eDocument in one or more of the following fields:
    • Supplier Invoice: Company Name, NIF,  Reporting Period, Reporting Year, Tax Fulfillment date, Tax Base amount, Tax amount, Tax Rate
    • Additionally, for Customer Invoices: Equalization tax amount, Equalization tax rate, VAT amount not subject due to localization rules, VAT amount not subject due to  other reasons, Exempted VAT amount

 

B) Consistency between a source document, such as a journal entry, and the corresponding eDocument

• Existence Checks.
  •  eDocument Missing for Tax Authority Document

C) Consistency between a reversal document and the invoice record stored in the tax authority's portal:

• Existence Checks
  •  eDocument Missing for Tax Authority Document
  • eDoc Missing for Reversal Journal Entry
• Status Checks
  • Reversal Journal Entry Not Submitted The eDocument is reversed but in the tax agency portal is not.

Within each layer, there are specific result processes (see the next section for the full breakdown). All these is visible in the App:

 

5. Resolve inconsistencies in the Resolve app

The app groups inconsistencies into tabs, one per result process. 

Select the relevant tab and follow the action available for each inconsistency. Most resolutions are one-click operations.

For bulk resolution, select multiple records and process in the background to avoid blocking the UI. It is also possible to see the history of resultion:

 

Further Reading

In case of additional questions, you can visit the SII help documentation in the following links:

• Consistency checks for Spain in S/4HANA Public Cloud
• Consistency checks for Spain in S/4HANA Private Cloud
• Electronic Tax Register Books with SII in S/4HANA Public Cloud
• Electronic Tax Register Books with SII in S/4HANA Private Cloud
• Electronic Tax Register Books with SII in ERP
• Other SII tips: Spain – SAP Document and Reporting Compliance → Related Links → Community section

 

 

Disclaimer

This blog post reflects the author’s interpretation of Spanish legal requirements and SAP system behavior as of the publication date. It is intended for informational purposes only and does not constitute legal advice. For specific guidance, consult your legal or tax advisor and refer to official SAP documentation.

The links to external sources in this blog may be modified at any time externally by the owner without previous notice.

Source link