This practical guide explains, step by step and in plain language, how to convert quotes into legally valid invoices and set up automatic online collections for an SME. It covers the essential legal requirements, recommended technical components (CRM/ERP, invoicing engine, electronic signature, payment gateway) and a practical checklist to launch the flow securely.
Important: the regulatory framework and public schemes change over time. Before publishing or applying changes to your accounting, always verify the current rules at the official sources linked in the Resources section (Agencia Tributaria, BOE, Facturae, FACe). I have linked the official portals in the sections below to make that verification easier.
¿Es legal convertir un presupuesto en una factura?
Concept and basic difference
- Quote / offer: a commercial proposal listing prices and terms; it is not a fiscal invoice by itself.
- Invoice: a document with accounting and tax effects; its issuance must respect numbering, mandatory content and recognition rules (devengo).
Issuing an invoice without respecting numbering, required content or the correct recognition moment can create tax risks. For the official and up-to-date list of mandatory data and invoicing rules consult the Agencia Tributaria electronic office: https://sede.agenciatributaria.gob.es/ and the BOE repository: https://www.boe.es/.
Minimal flow (text)
- Quote issued -> Client accepts (email, portal, electronic signature) -> Acceptance recorded in CRM -> Generate invoice (controlled series and numbering) -> Send to client and record in accounting.
What to check before automating
- Acceptance record: type (email, portal, signature), date and link to the order/invoice. Practical recommendation: store for each acceptance at least a unique identifier, timestamp (ISO 8601), IP address, user agent, sender email and the SHA‑256 hash of the accepted document. Attach that identifier to the invoice (as metadata) for traceability.
- Numbering and series: controlled, sequential and auditable. Define policies to lock series in production environments and recovery procedures.
- Mandatory invoice fields: issuer and recipient (NIF), date, numbering, a sufficiently detailed description of the transaction, taxable base, VAT rate and amount, total, etc. Consult the AEAT for the complete list: https://sede.agenciatributaria.gob.es/.
Proforma invoice vs quote vs invoice
- Quote: a commercial document; not a fiscal document by itself.
- Proforma invoice: an informative document that does not replace the fiscal invoice.
- Invoice: the document with fiscal effect. Do not turn a proforma into an invoice without a clear record of client acceptance.
For specific cases consult the Agencia Tributaria and, where appropriate, your tax adviser: https://sede.agenciatributaria.gob.es/.
Minimum requirements for a valid invoice in Spain (indicative)
Indicative checklist (always confirm with AEAT/BOE):
- Identification of issuer (company name, NIF) and recipient (name/company and NIF).
- Issue date and sequential invoice number (series and numbering).
- Sufficient description of the operations.
- Taxable base, VAT rate and VAT amount.
- Total and currency where relevant.
- References to special regimes or intra‑community operations if applicable.
These obligations and specific exceptions must be confirmed in the tax legislation in force: https://sede.agenciatributaria.gob.es/ and https://www.boe.es/.
Recommended technical architecture to automate the flow
Minimum recommended stack
- CRM/ERP: manage quotes, record acceptance and maintain the customer master.
- Invoicing engine: generate PDF invoices and, where needed, export to the Facturae XML format. Facturae portal: https://www.facturae.gob.es/.
- Electronic signature / identity service: when advanced or qualified signature is required (see eIDAS): https://eidas.ec.europa.eu/.
- Payment service provider (PSP): payment links, tokenisation, virtual POS and SEPA direct debit.
- Bank reconciliation module: automatic assignment of payments to invoices (via webhooks or bank statements).
- Secure storage: archival with backups and retention policies.
Key technical integrations
- API to create invoices from the ERP/CRM; document endpoints, payloads and error codes.
- Webhooks for payment events (e.g. Stripe publishes webhook events; see Stripe Webhooks: https://stripe.com/docs/webhooks) and to confirm invoice settlement. Practical example: listen for the event that confirms payment settlement and map it to the invoice number and the unique acceptance identifier.
- Reconciliation endpoint that receives notifications and maps them to invoice number / internal reference.
- Exporter to Facturae when legislation or the client requires it, and submission to FACe for invoices to the Administration: https://face.gob.es/es and https://www.facturae.gob.es/face.
What to check in suppliers
- API/webhook compatibility with your ERP.
- Contractual terms and data protection clauses (check the Terms/Contracts of each PSP).
Core components (responsibilities and checks)
- CRM/ERP: must map quote fields to the invoice, store the acceptance record (date, method, user, acceptance ID and document hash) and expose APIs to create invoices.
- Invoicing engine: generate PDF and, where applicable, produce Facturae XML according to the official format (see https://www.facturae.gob.es/ for format and validators). Validate the XML in a test environment before producing batches for submission.
- Electronic signature: the eIDAS Regulation governs signature types; consult the EU eIDAS portal: https://eidas.ec.europa.eu/ to decide whether you need a qualified signature or whether an acceptance record suffices.
- PSP / Gateway: PSD2/SCA compliance and webhook issuance. Review technical documentation of the chosen PSP (for example, Stripe: https://stripe.com/, PayPal: https://www.paypal.com/es/home, Redsys: https://redsys.es/, Bizum: https://bizum.com/es/).
- Reconciliation: the provider handling reconciliation should allow automatic rules (by invoice reference, amount and OCR of descriptions) and retain traceability for audit.
Implementation, step by step (practical)
Step 0 — prepare: data and policies
- Verify clients’ NIFs and fiscal data in the CRM.
- Define quote and invoice templates including every field required by the regulation.
- Draft commercial terms and an acceptance policy (what constitutes valid acceptance).
- Document numbering policy and version control.
- Review GDPR requirements: legal basis for processing payment data, contracts with PSPs and SEPA mandates where applicable.
Step 1 — configure the flow in CRM/ERP
- Map quote fields to the invoice template (ensure the operation description is sufficient to meet tax requirements).
- Define the “acceptance” event that will trigger invoice creation (for example: button on a portal, an email with a specific phrase, or electronic signature).
- On the event, generate a draft invoice and run validations: mandatory fields, taxes, numbering and duplicate checks.
- Record a unique identifier that links the quote, acceptance and invoice. Include in the record the metadata noted above (timestamp, IP, user agent, document hash and sender email).
Tests: perform conversions in a test (sandbox) environment and keep audit logs (who acted, when, what document was generated). Make sure to test flows with failed payments and retries. Operational recommendation: run tests covering at least the following scenarios: invoices with different VAT rates, intra‑community invoices, invoices with discounts or returns, and reconciliation of partial payments.
Step 2 — fiscal validity and export to Facturae/FACe
- Determine whether you need Facturae (for example, invoicing public administrations). Official format and rules are on the Facturae portal: https://www.facturae.gob.es/ and, for submission to the Administration, the FACe Entrance Point: https://face.gob.es/es.
- Integrate Facturae (XML) generation and validate the XML with the official tools before sending.
- If you opt for electronic signatures, consult eIDAS to decide if a qualified signature is necessary or if the acceptance record is sufficient; for specific tax cases consult your tax adviser.
Step 3 — integrate the payment gateway and automatic collection
- Choose the method: payment link (single invoices), virtual POS (web integration) or SEPA direct debit (for recurring collections).
- For SEPA direct debit, manage the SEPA mandate and store it in compliance with applicable rules and the PSP.
- For recurring payments, use the tokenisation provided by the PSP to avoid storing card data on your servers and reduce GDPR risk.
- Implement SCA: the first authorisation of some payments and certain payment methods require strong customer authentication (PSD2/SCA). Consult your PSP’s documentation and the European Banking Authority guidance: https://www.eba.europa.eu/.
- Test in sandbox and simulate SCA rejections to design recovery flows (retries, re‑authorisation emails).
Step 4 — reconciliation and accounting entry
- Configure PSP webhooks that notify payments and failures (for example, Stripe and other PSPs provide webhooks to automate reconciliation; see https://stripe.com/docs/webhooks). If you use Stripe, include events that confirm the payment was successful (refer to the PSP documentation).
- Define reconciliation rules: invoice reference + amount + customer.
- When the webhook confirms payment, mark the invoice as paid and generate an accounting entry referencing the invoice.
- Maintain an audit trail (logs, invoice copies, webhook events) for inspections.
Payment methods and PSD2/SCA compliance
- Payment links: convenient for one‑off invoices; SCA compliance depends on the provider and the transaction type.
- Virtual POS (Redsys or others): integration with your commerce and likely application of SCA (Redsys: https://redsys.es/).
- SEPA direct debit: requires SEPA mandates; use it for recurring payments where the business model allows.
- Tokenisation: reduces friction for recurring charges, although the first transaction typically requires SCA.
Consult the PSP documentation before finalising the technical implementation (for example, Stripe: https://stripe.com/, PayPal: https://www.paypal.com/es/home, Bizum: https://bizum.com/es/).
Risks and mitigations (practical summary)
- Tax risk from incorrect invoices: mitigate by validating templates with a tax adviser and testing in a pre‑production environment.
- SCA/PSD2 payment rejection: inform the customer about authentication requirements and implement re‑authorisation flows.
- GDPR non‑compliance: do not store card data on your servers; use tokenisation and sign contracts with the PSP that include data protection clauses.
- Third‑party dependency: negotiate SLAs, keep backups and plan contingencies (alternative payment option or data export).
Checklist before go‑live
- [ ] Acceptance record (method, date and link to the invoice). Ensure the record includes timestamp, IP address, user agent and document hash.
- [ ] Invoice template with all mandatory fields (see AEAT/BOE).
- [ ] Numbering and series control implemented.
- [ ] Facturae generation tests if applicable (validate XML with official validators: https://www.facturae.gob.es/).
- [ ] PSP configured in sandbox and SCA tested.
- [ ] Contract with PSP including data protection and liability clauses.
- [ ] Retention and backup policy defined.
Mini‑cases (hypothetical and didactic)
1) One‑off service: quote accepted by email -> acceptance recorded -> invoice issued with a payment link -> client pays via PSP and webhook confirms payment -> automatic reconciliation.
2) Phased project: contract with deliverables and milestone billing -> acceptance of each milestone generates a partial invoice -> SEPA direct debit for advances if appropriate (manage mandates).
3) Subscription: signup with card and tokenisation -> first charge with SCA -> subsequent charges with the token.
In all cases, document acceptance and retain evidence for audit (logs, copies of the accepted document, acceptance ID and associated hash).
Resources and official links (always check versions and dates)
- Agencia Tributaria (electronic office): https://sede.agenciatributaria.gob.es/
- Facturae (format and tools): https://www.facturae.gob.es/
- FACe (General Entry Point for invoices): https://face.gob.es/es
- eIDAS (trust services and signature types): https://eidas.ec.europa.eu/
- BOE (official legislation): https://www.boe.es/
- Kit Digital / Red.es (note: their last call closed on 31/10/2025; no new call has been announced; check here for updates): https://www.red.es/es/iniciativas/proyectos/kit-digital
- Stripe (technical documentation, payment links and webhooks): https://stripe.com/docs/webhooks
- Redsys (virtual POS and documentation): https://redsys.es/
- Bizum (service information): https://bizum.com/es/
- PayPal (business services information): https://www.paypal.com/es/home
- EBA (PSD2/SCA guidance): https://www.eba.europa.eu/
Conclusion and recommended next steps
Automating the flow from quotes to invoices and online collection is feasible and brings efficiency, but it requires checking legal and technical requirements before moving to production. Practical recommendations:
- Test everything in a sandbox and validate with your tax adviser.
- Implement audit trails and acceptance records with the recommended metadata.
- Do not store sensitive payment data on your servers; use tokenisation.
- If you need help, plan a technical audit of the flow (architecture, tests and contingency plan).
If you would like us to evaluate your specific case and plan the automation according to your ERP and volumes, contact Momentum to arrange a Free Assessment; terms and availability will be confirmed during the commercial conversation.
This article was drafted with the support of artificial intelligence and reviewed by qualified Momentum Logic AI staff before publication.
- Momentum Logic AI Team . https://momentumlogicai.es . https://linkedin.com/company/momentumlogicai
Leave a Reply