Spain FACe Guide: Public-Sector E-Invoicing for Suppliers

FACe is Spain's official entry point for suppliers sending electronic invoices to public administrations. If you need a Spain FACe guide, the rule of thumb is simple: before you submit, you usually need a compliant structured invoice, the correct DIR3 routing codes, and the certificate or signature setup your submission method accepts. If you are billing a Spanish public body on a covered public-sector contract above EUR 5,000, you should expect electronic submission through FACe rather than a paper or PDF-only process. Under Ley 25/2013, electronic submission through FACe has been mandatory for suppliers billing Spain's General State Administration since January 15, 2015, according to official Facturae guidance on mandatory public-sector e-invoicing.

For Spain public sector e-invoicing, FACe is the front door and the status surface, but it is not the authority that decides every outcome on its own. FACe receives the invoice, routes it to the relevant public body, and shows submission status, while substantive rejection reasons and payment updates come from the receiving administration.

This guide focuses on the FACe public-sector workflow. FACeB2B, SII, VeriFactu, and TicketBAI are separate systems with different purposes, which we cover later.

What You Must Prepare Before Sending a FACe Invoice

Before you attempt a FACe invoice submission, make sure you are not mixing up three separate tasks: creating the invoice file, validating it, and actually transmitting it through FACe. Most failures happen because the XML is structurally valid but the sender has not prepared the signature, certificate, or recipient data needed for a successful submission. In practice, a clean Facturae XML Spain file, a compatible signing setup, and the correct administrative identifiers all have to line up at the same time.

For Spanish public-sector invoicing, Facturae is still the default starting point. FACe's own tooling is built around Facturae 3.2, 3.2.1, and 3.2.2, so those are the versions suppliers should treat as the working baseline when they prepare a file for public bodies. If your ERP or invoicing engine produces other structured formats such as UBL 2.1 or UN/CEFACT CII, confirm that the receiving workflow and your submission method support them in practice. Many suppliers still default to Facturae to reduce compatibility questions at submission time.

The signature layer matters just as much as the invoice content. FACe submissions are tied to XAdES electronic signatures, and the surrounding government tooling is designed to validate and manage certificates through the @firma infrastructure. In operational terms, that means the invoice file cannot be treated as a standalone XML export. The file has to be signed by a certificate that your organization can actually use for public-sector submissions, and that certificate must match the legal entity that is sending the invoice.

This is where internal setup often breaks down. Your invoice data, your sender identity, and your certificate holder need to represent the same supplier entity. If the legal name, tax identifier, registered address, or authorized signing entity are inconsistent across systems, FACe can reject the submission even when the invoice contents look correct. Foreign suppliers feel this friction more often because they may need to align home-country registration details, local tax identifiers, and signing credentials before the first invoice will pass cleanly.

If you are working from an ERP or a shared finance workflow, prepare the master data before you touch the portal: the supplier entity details, the public body's routing information, and the signing configuration should all be verified first. That preparation is what turns a technically valid invoice file into a successful Facturae FACe submission.

How the FACe Submission Workflow Works in Practice

The clearest way to think about how to send electronic invoices to Spanish government bodies is this: you prepare the invoice on your side, FACe receives and routes it on the public body's side. The current supplier experience centers on the Spain government invoice portal at proveedores.face.gob.es/inicio, while older face.gob.es pages often function as reference material rather than the active day-to-day submission path.

The workflow usually moves in five steps. First, confirm the recipient routing data before you do anything else, because FACe needs the invoice to reach the right public body. Second, prepare the invoice in the required structured electronic format and make sure it is signed correctly. Third, decide whether you will submit through the web portal or through system-to-system integration. Fourth, send the invoice. Fifth, store the receipt, reference number, or tracking details so you can prove submission and follow the file through the queue.

For many finance teams, the portal is enough. It is the right route when you are sending a small number of invoices, testing a new supplier process, or dealing with a one-off public-sector customer. In that path, you upload the structured invoice, review the sender and routing data, and save the confirmation or registry reference that FACe returns. System-to-system submission matters when the invoice flow must live inside an ERP or AP platform, or when the volume is high enough that manual portal entry would create delays and errors. In that case, the web services layer is used to automate submission, capture the acknowledgment automatically, and store the tracking identifier inside your billing workflow.

What you do before upload is different from what FACe does after receipt. Your job is to make the invoice technically ready, correctly signed, and routed to the right recipient. FACe's job is to accept it, validate the submission, and pass it into the public administration's internal handling process. If the invoice is rejected or blocked, the starting point is usually still the supplier side, because the issue is often with formatting, routing, signing, or recipient data rather than with the act of transmission itself.

For cross-border suppliers and ERP implementers, the main operational decision is simple: if a human can reasonably submit the invoice through the portal, use the portal; if the invoice flow must be embedded in your billing system, use system-to-system submission. That distinction keeps Spain B2G invoicing manageable in practice, because it separates the public portal workflow from the automated integration workflow without turning the process into a generic platform exercise.

DIR3 Codes and How to Verify Them Before You Submit

DIR3 is the routing framework that tells Spain's public-sector system which internal bodies should receive and process your invoice. If the code is wrong, the invoice may still be technically valid, but it can fail operationally because it reaches the wrong office, stalls in review, or is rejected for mismatched routing. In Spain public sector e-invoicing, DIR3 codes are one of the most common failure points when the invoice file itself is fine.

The three DIR3 fields matter in different ways:

• Oficina Contable is the accounting office that records and checks the invoice from a financial control perspective.
• Organo Gestor is the managing body responsible for the spending decision and the underlying contract or order.
• Unidad Tramitadora is the processing unit that handles the invoice workflow and day-to-day administrative follow-up.

Think of them as three separate routing checkpoints, not interchangeable labels. A code can be correct for one public body and still be wrong for the specific contract, department, or purchasing entity tied to your invoice.

A usable lookup workflow is usually simple, but it needs to be disciplined:

1. Start with the contracting authority's invoice instructions, purchase order, award documents, or supplier onboarding materials.
2. Cross-check each code against the authoritative recipient or DIR3 information the administration publishes, rather than against an old file, template, or previous invoice.
3. Confirm the codes match the exact receiving body and contract context, including the correct department, site, or administrative unit.
4. If the authority gives you more than one set of codes, verify which set applies to the specific invoice line, contract, or purchase order you are submitting.

If a code looks inconsistent, outdated, or copied from a different entity, re-check the legal name of the public body, the contract or PO reference, the invoice recipient unit, and whether the invoice is meant for a central office or a local branch. Do not assume that a code used successfully on a previous job will work again. Reused DIR3 data is a common source of misrouting, especially when billing multiple bodies within the same administration or when a contract has been transferred to a different unit.

What FACe Statuses and Rejections Actually Mean

In FACe, the first message you see is usually only an acknowledgment that the invoice was received, not proof that it was accepted for processing or approved for payment. Treat that initial status as an upload confirmation. The real operational decision happens later, when the receiving administration or accounting office validates the invoice, accepts it, rejects it, or updates payment progress.

That distinction matters because FACe mainly exposes downstream decisions back to you. The portal is not the party making the substantive call on whether the invoice is valid, payable, or ready to move forward. If the status changes, the body that issued the update is usually the one you need to contact or correct against, because the recipient controls the workflow that follows submission. If the recipient does not update its records promptly, FACe tracking will be only as informative as that administration's own behavior. Where the receiving administration follows the standard reporting flow, suppliers should normally see status feedback within four working days, so a longer silence is a cue to follow up with the recipient rather than assume FACe itself is the problem.

A FACe invoice rejection usually points to a problem that the receiving body found during validation or routing. In practice, the most common root causes are the ones you should check first: the invoice was sent to the wrong office, the DIR3 codes do not match the intended recipient, the file format or required fields are incomplete, or the signature and authority details are not acceptable. If the invoice is stalled rather than formally rejected, that often means it is waiting on a downstream review, sitting in an internal queue, or blocked because the recipient has not issued the next status update.

When a status is unclear, work backward from the source of the update. Identify which body issued the message, verify whether the issue belongs to routing, format, signature, or invoice content, and then follow that administration's resubmission or correction path. If the rejection came from the accounting office, fix the invoice and resubmit only after the underlying issue is corrected. If the invoice is accepted but payment is still pending, the next step is usually follow-up with the recipient, not resubmission, because acceptance and payment are separate events.

Common Problems for Foreign or First-Time Suppliers

The first FACe submission usually fails for simple setup reasons, not because the invoice amount is wrong. Teams new to Spain FACe e-invoicing often prepare the invoice correctly, then discover they were using the wrong portal flow, missing a certificate prerequisite, or routing to the wrong public body. In Spain B2G invoicing, the hardest part is often the administrative setup around the document.

For foreign suppliers, the friction is usually higher. Confirm early whether you need Spanish NIF or entity-identification details for the supplier record, whether your setup can authenticate with the certificate type the portal accepts, and whether those details match the buyer's routing expectations before you prepare or sign the invoice.

Before the first attempt, ask the public-sector customer for the full DIR3 trio, any buyer-specific routing instructions, the structured format they expect, and the operational contact who handles invoice issues. Do not rely on a purchasing contact who only knows the commercial relationship. If the routing data is incomplete or stale, the invoice may be technically valid but still land in the wrong place or remain unprocessed.

If your team also handles neighboring public-sector portals, a nearby public-sector e-invoicing workflow with portal, certificate, and status-tracking parallels offers a comparison point. In Spain, though, the most common failures still come back to DIR3 accuracy, Spanish identification details, and certificate readiness.

How FACe Differs From FACeB2B, SII, VeriFactu, and TicketBAI

FACe is the Spain public sector e-invoicing channel. Use it when you are sending an electronic invoice to a ministry, municipality, agency, university, or another public administration that requires invoice entry through the state's official gateway. That is different from the other Spain compliance acronyms finance teams often see at the same time.

FACeB2B is for business-to-business invoice exchange between private counterparties, not for routing a supplier invoice into a public body's accounting flow. SII is near-real-time VAT ledger reporting to the tax authority. VeriFactu is about invoicing software and record integrity. TicketBAI is a Basque regional tax-control regime. A supplier can have obligations in one or more of those systems, but meeting them does not replace FACe for public-sector invoice submission.

If you need the broader policy map, Spain's wider map of FACe, VeriFactu, SII, TicketBAI, and Crea y Crece lays out how those systems fit together. For the operational task this article focuses on, the key question is simpler: are you trying to submit a Spain B2G invoice to a public body? If yes, FACe is the system you need to prepare for, with the right format, signature setup, and DIR3 routing data.

A Practical Checklist Before You Send a FACe Invoice

As a final step in this Spain FACe guide, confirm each of these points before you submit:

• The buyer is a Spanish public-sector entity and this invoice falls within the FACe workflow for that body.
• Your invoice is in the required structured format, with the correct Facturae or other accepted schema version for the recipient's process.
• The signature or certificate setup is ready, and the submitting entity details match the supplier information that the administration expects.
• The DIR3 trio is complete and verified: Oficina Contable, Organo Gestor, and Unidad Tramitadora.
• You know whether the invoice will be submitted through the portal or through a system-to-system channel.
• The team handling the invoice has the acknowledgment or reference it will need for follow-up after submission.
• You know who at the receiving administration to contact if the invoice is rejected, stalled, or needs corrected routing data.

Remember that successful entry into FACe is not the same as acceptance for processing or payment. FACe can confirm submission and surface updates, but the receiving administration still controls review, rejection, and payment status.

If the transaction also creates separate Spain-specific reporting questions, check Modelo 347 reporting rules for higher-value third-party transactions in Spain alongside your invoice workflow. That is a different obligation from how to send electronic invoices to Spanish government bodies through FACe, but it can matter in the same finance process.