Momentum Logic AI Blog

Category: Invoicing

  • Dental clinic: how to verify reported reductions in overdue payments

    Dental clinic: how to verify reported reductions in overdue payments

    In this article we explain what vendors typically report about improvements in overdue payments after implementing automated dunning and AI‑driven reminders, what you should check before making decisions, how to measure the impact in your own dental clinic and the key legal requirements (GDPR/LOPDGDD).

    Throughout you will find: a summary of the evidence and its verification level; a past/present/future table with the cut‑off date; a technical and operational description of commonly automated features; a practical methodology to measure reduction in overdue payments; a legal and operational checklist; an illustrative numerical example; and concrete steps to pilot this in a dental clinic.

    Executive summary and evidence verification level

    What has been published and what it means

    • In the AR/dunning sector it is common for vendors to publish case studies and marketing materials claiming improvements in on‑time payments after deploying automated sequences and AI scoring. These figures frequently appear in commercial collateral; however, treat them as ‘vendor‑reported’ until primary verifiable evidence is supplied.
    • Verification status: in our review as of reference date 2026‑09‑09 we did not find public, independent primary documentation that confirms, for a named dental clinic case, a specific reduction in overdue payments verifiable by an external audit. Therefore, this article preserves any concrete percentages as vendor/marketing reports and explains what to request to verify them before relying on them for purchasing decisions.

    What to ask for when you want to verify a specific claim

    • Accounting report detailing the compared periods and the exact KPI definition (for example: the numeric definition of “overdue payments” used).
    • The compared periods and sample size (number of invoices, total invoiced amount in each period).
    • Evidence that there were no simultaneous changes (discounts, commercial policies, external collection campaigns) that could explain the difference.
    • External audit or certification of the outcome, if available.

    If you do not have primary documentation for a claim, use a mitigated headline like this article: “reported by vendors” and make it clear these figures come from commercial materials and must be verified with primary documentation.

    Verification box (summary)

    • Primary documentation available: NO (we have not located public, independent primary documentation that verifies a specific dental clinic case with a concrete figure as of publication date 2026‑09‑09). Request primary documentation from the vendor or clinic before quoting precise figures.
    • Vendor sources (examples): there are numerous vendor whitepapers and marketing materials in the AR/debt recovery sector; interpret those figures cautiously: ask for period, KPI definition, sample size and external audit if you require it.

    Table: past / present / future (context and trends)

    Reference date: 2026‑09‑09

    Period Summary
    PAST Progressive adoption over the last decade of automated reminders (SMS/email) and AR solutions. Relevant legal framework: Regulation (EU) 2016/679 (GDPR) and the LOPDGDD (2018). Facturae format is mandatory for invoicing public administrations. Sources: GDPR, BOE – LOPDGDD, Facturae.
    PRESENT As of publication date 2026‑09‑09 no public independent study was located that documents a dental clinic case with a concrete figure verifiable publicly. There are multiple vendor cases and whitepapers with approximate ranges reported in commercial materials. GDPR and LOPDGDD remain applicable; the AEPD is the competent authority.
    FUTURE Expected trend: more AI to personalise dunning sequences and predictive models for non‑payment. Regulatory risk: increased supervision over automated decisions and electronic communications; monitor AEPD updates after the publication date.

    What is typically automated: functional and technical components

    Common AR automation implementations for clinics include:

    • Automatic capture and registration of invoices from your ERP or clinical management system.
    • Automatic issuance and sending of invoices/receipts (PDF, email) and scheduled reminders.
    • Multichannel dunning: email, SMS, WhatsApp Business (with caution), automated or manual calls, and postal escalation.
    • Integrated payment gateways (virtual POS, payment links in email/SMS) to facilitate immediate payment.
    • Scoring and prioritisation with models using payment history, amount, ageing and patient behaviour to choose channel and tone.

    Suggested diagram: flow from “invoice generated” → “timing & scoring rules” → “channel selected” → “send” → “payment or escalate to human”.

    Examples of recommended messages and tone (do not copy vendor templates verbatim):

    • Pre‑due email (3 days before): friendly reminder tone, state amount, due date and payment link.
    • SMS on due date: brief, clear call to action with link.
    • WhatsApp (if used): obtain consent and avoid mentioning treatments; use a generic message about outstanding balance and payment options.

    Common multichannel dunning flow (typical practice)

    1. Reminder 3 days before due (email, informational tone).
    2. Notice on due date (SMS with payment link).
    3. 3 days post‑due: second email with payment options and an offer to agree instalments if appropriate.
    4. 14 days post‑due: more formal communication and an invitation to contact administration.
    5. 30–45 days: human escalation (collections team call or notice of further measures).

    Variants: for patients avoid mentioning any clinical details in messages; for B2B invoices you can be more specific. A/B test intervals and tone for your patient base (each clinic and demographic responds differently).

    If you would like hands‑on support with implementation at this stage, the architecture phase of the Momentum Process covers the definition of flows and scoring adapted to the clinic.

    How to measure reduction in overdue payments: definition, metrics and methodology

    Operational definition of “overdue payments” (suggested for comparison):

    • Overdue payments (%) = (Amount overdue and unpaid in period X) / (Amount invoiced in period X) * 100.

    Alternative and complementary metrics:

    • DSO (Days Sales Outstanding): average days to collect from invoice date.
    • % on‑time payments: percentage of invoices paid on or before the due date.
    • Recovery rate: amount recovered after dunning actions vs amount initially overdue.

    Recommended methodology to attribute effect to automation:

    1. Define the KPI clearly (e.g. Overdue payments using the formula above).
    2. Comparable period: minimum 3–6 months before vs 3–6 months after; 6 months is more robust to remove seasonality.
    3. Control variables: do not change relevant commercial terms (e.g. discounts, financing) or collection policies during the pilot period.
    4. Preferable: design an A/B pilot (control group using the current process vs treated group with automation) to isolate the effect.

    Practical before/after calculation example (illustrative)

    Assumptions (illustrative example):

    • Monthly invoicing: EUR 50,000.
    • Compared period: 6 months.
    • Total overdue amount before (6 months): EUR 6,000 (overdue 2.0% using the suggested definition).
    • Total overdue amount after (6 months with automation): EUR 3,600 (illustrative).

    Calculation (illustrative):

    • Overdue before = EUR 6,000 / (EUR 50,000 * 6) = EUR 6,000 / EUR 300,000 = 2.0%.
    • Relative reduction (illustrative) = (EUR 6,000 – EUR 3,600) / EUR 6,000 = 40% less overdue amount.

    Warning: this example is illustrative and assumes there were no other changes. If variables are not controlled, attribution to the automated system is uncertain.

    Legal compliance and data protection (critical for dental clinics)

    Key obligations:

    • Applicable framework: GDPR (Regulation (EU) 2016/679) and LOPDGDD (Ley Orgánica 3/2018). In Spain the AEPD publishes practical guidance on electronic communications and vendors.
    • Health data: if a message reveals information about treatments it is a special category (art. 9 GDPR) and requires stronger safeguards and, generally, a more secure legal basis.
    • Possible legal bases for collection communications: performance of a contract (when a contractual relationship exists), legitimate interest (with a necessary balancing test) or consent (where applicable). Document the chosen legal basis and the corresponding analysis.
    • DPIA (data protection impact assessment): recommended when the system includes automated profiling with significant effects on individuals (for example, scoring that leads to adverse decisions). Practical recommendation: consult AEPD guidance and document the DPIA.
    • Contracts with vendors: include a data processor clause, details on international transfers, technical measures (encryption, restricted access), retention periods and subcontractors.

    Messaging good practices:

    • Avoid any reference to treatments or clinical details in collection messages.
    • Offer channel options and communication preferences/consent.
    • Keep logs and communication histories and document the legal basis.
    • Limit frequency and ensure a respectful, proportionate tone.

    Risks by channel (WhatsApp, SMS, email)

    • WhatsApp Business: commonly used but relies on a third party that may process metadata and, in some cases, transfers outside the EU; review processor clauses and guarantees.
    • SMS: cost per message and delivery variability; less control over content security.
    • Email: deliverability and phishing risks; require authentication measures (SPF/DKIM/DMARC) and clear templates.

    Minimum checklist to assess vendors:

    • Do they provide a data processor clause and a subcontractor model?
    • Where are the data stored (EU/EEA or third countries)?
    • What technical (encryption at rest/in transit, data segregation) and organisational measures do they apply?
    • Do they allow audits or provide security reports?
    • Do they facilitate deletion and portability under GDPR?

    Operational, reputational and ethical risks and how to mitigate them

    Key risks and practical mitigations are described above: segmentation, empathetic tone, human escalation, periodic audits, and templates validated by legal counsel. Maintaining these practices reduces litigation and complaints.

    Cost, expected ROI and commercial considerations

    Costs to consider:

    • SaaS subscription (monthly or annual).
    • Per‑message costs (SMS/WhatsApp) and payment gateway fees.
    • Technical integration (hours/consultancy fees) with your management system.
    • Team training and process adjustments.

    Simple ROI template (illustrative):

    • Initial investment (setup + integration): EUR 3,000 (illustrative).
    • Annual recurring cost (SaaS + messages): EUR 2,400 (illustrative).
    • Estimated saving from reduced overdue amounts (illustrative): if the clinic currently has EUR 6,000 overdue in 6 months and reduces by 40% → saving of EUR 2,400 in 6 months (illustrative).
    • Approximate payback: investment recovered in ~8–12 months in this scenario (illustrative).

    Recommendation: ask the vendor for period‑by‑period breakdowns, KPI definitions and sample sizes before accepting percentage claims.

    Practical step‑by‑step guide to implement in your dental clinic

    Implementation checklist (8 steps):

    1. Data audit: contact quality, duplicates, valid emails/SMS numbers.
    2. KPI definition: agree how you will measure “overdue payments” and the comparison period.
    3. Vendor selection: verify technical and legal criteria (see checklist above).
    4. Pilot design (A/B) and control group definition.
    5. Integration with billing/ERP systems and payment gateway.
    6. Configure sequences, scoring and templates (avoid clinical content).
    7. Monitor (DSO, % on‑time payments, recovery rate) and adjust weekly during the pilot.
    8. Legal documentation: contracts, legal basis, DPIA if applicable, retention policies.

    Recommendations for the pilot: sufficient sample size for statistical signal (for example 200–500 invoices in 3 months) and minimum duration 3 months; 6 months is preferable for stability. These figures are indicative.

    If you want practical help with the pilot or technical integration, Momentum Logic AI can support you from the initial audit through pilot deployment.

    Note: for a broader view on automating recurring billing and bank reconciliation with AI —tasks complementary to collections— consult our pillar guide on invoice automation and bank reconciliation with AI on the Momentum Logic AI blog.

    Comparison of solutions: specialised AR SaaS vs ERP modules vs bespoke development

    Practical summary: specialised AR SaaS usually offers speed and multichannel dunning; ERP modules give more data control if your ERP supports it; bespoke development provides customisation but higher cost and time. Choose according to volume and desired control.

    Sources, vendor cases and how to interpret them

    Primary legal sources cited in this article:

    Vendor cases and materials (verification note): there are many vendor marketing materials in the sector. Before reproducing percentages or concrete figures, request primary documentation from the vendor or clinic.

    Conclusion and next steps for the reader

    Practical conclusion: automation can improve collections for many clinics, but any concrete figure in vendor materials must be verified with primary documentation. Prioritise proper measurement (define KPI and period), design an A/B pilot and ensure GDPR compliance, particularly if there is a risk of revealing health data.

    Recommended next step: perform a data audit and a controlled pilot before scaling. If you would like us to evaluate your specific case, request a Free Assessment and we will cross‑check KPI definitions and pilot design.

    This article was drafted with the support of artificial intelligence and reviewed by qualified Momentum Logic AI staff before publication.

    — Momentum Logic AI Team . momentumlogicai.es . LinkedIn

    Keep reading

  • Automate Facturae and SII with AI agents — practical, verified guide

    Automate Facturae and SII with AI agents — practical, verified guide

    Introduction

    Automating the issuance and submission of invoices in Facturae XML format to the SII with AI agents can save time and reduce errors, but you must verify technical prerequisites and tax obligations before going live. This guide explains the technical and regulatory components you need, an operational step‑by‑step flow, GDPR and security controls, and the tests required to move to production.

    Reference date for legal and technical checks: 09/09/2026. Before implementing, always confirm the XSD/WSDL, authentication methods and official listings on the AEAT and the Facturae portal (links under Official resources at the end).

    Overview: what each system is and why they differ

    Facturae (format and versions)

    Facturae is Spain’s official XML format for electronic invoicing, intended among other uses for exchange with public administrations and systems that require a standardised XML. The official portal publishes the XSD schemas and technical documentation needed to validate files.

    • Facturae portal (schemas and documentation): https://www.facturae.gob.es/
    • Practical note: before generating Facturae in production, download and validate against the official XSD for the version in force from the Facturae portal above.

    SII (what it sends, purpose and scope)

    The Suministro Inmediato de Información (SII) is a system managed by the Agencia Estatal de Administración Tributaria (AEAT) for receiving invoicing records (issued and received invoice data) to improve VAT control and traceability. The AEAT maintains a technical section with service manuals for submitting data.

    • SII documentation and manuals (AEAT): https://sede.agenciatributaria.gob.es/Sede/iva/suministro-inmediato-informacion.html
    • Note: obligation and scope of SII vary according to AEAT resolutions and criteria; not all companies are required to participate. Check the official list and associated resolutions on the AEAT electronic office before making decisions.

    FACe and VERI*FACTU: operational roles and differences

    • FACe is the Central Entry Point for invoices directed at Public Administration bodies; its purpose is to receive invoices intended for public organisations (FACe portal: https://proveedores.face.gob.es/).
    • VERIFACTU (VERiFACTU / VeriFactu) is the AEAT technical framework oriented to verifiable invoicing and to Billing Information Systems (SIF); it defines technical and functional requirements that may apply depending on use and volume (AEAT — VERI*FACTU): https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu.html

    None of these services is identical to the SII: FACe handles invoice reception for public bodies; SII handles VAT reporting to the AEAT. VERI*FACTU provides verification mechanisms and technical requirements with scope and conditions set out in the linked official documentation.

    Who is obliged and what voluntary options exist?

    Whether an entity is required to use SII depends on specific provisions published by the AEAT (resolutions, orders and criteria). Do not generalise: consult the official list and published resolutions.

    How to check if your company is obliged (practical steps)

    1. Visit the SII section on the AEAT electronic office and review the available information and regulations: https://sede.agenciatributaria.gob.es/Sede/iva/suministro-inmediato-informacion.html
    2. Check the regulation or resolution that details obliged subjects and rollout dates (consult resolutions and orders in the BOE: https://www.boe.es/).
    3. If in doubt, consult your tax adviser or AEAT support channels (contact details on the AEAT electronic office).
    4. Keep a screenshot or reference (date and URL) of the document consulted as part of your compliance records.

    Mandatory technical checks before integrating (verify with AEAT)

    These are the key technical pieces you must confirm in the official manuals before developing or procuring a solution.

    Facturae schemas and XML validation

    • Validate XML against the official XSD for the Facturae version indicated on the portal. Common critical fields: issuer/recipient identifiers (NIF), taxable bases, VAT rates, bases and totals, invoice series and number, issue date and operation codes.
    • Include XSD validation in your local pre‑send pipeline and reject invoices that fail validation. Download schemas and documentation from: https://www.facturae.gob.es/

    Authentication and access methods for AEAT services

    The AEAT publishes connection details (WSDL/web services) and procedures for access and authentication. Specific requirements (certificates, service identifiers, WSDL, endpoints) appear in the SII technical documentation and the service description PDFs:

    • SII (AEAT): https://sede.agenciatributaria.gob.es/Sede/iva/suministro-inmediato-informacion.html
    • SII web service description (technical PDF): https://sede.agenciatributaria.gob.es/staticfiles/Sede/Procedimientoayuda/G417/FicherosSuministros/V11/SII-Descripcion-ServicioWeb-v1-1eses.pdf

    Avoid assuming OAuth or other undocumented methods: rely on the official guide and the WSDL/PDFs published by the AEAT for access and credential acquisition.

    Signing, sealing and integrity requirements

    Some flows (and especially specific SIF/VERIFACTU models) may impose additional integrity, sealing or registration requirements. Whether you must sign the XML or whether channel authentication suffices depends on the service and schema version; consult AEAT technical documentation and VERIFACTU requirements:

    • AEAT — SII: https://sede.agenciatributaria.gob.es/Sede/iva/suministro-inmediato-informacion.html
    • AEAT — VERI*FACTU: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu.html

    Do not assume a signing requirement without confirming it in the official documents: check the service PDF and the VERI*FACTU sections.

    Limits, submission rates, timings and retry policies

    The AEAT publishes service specifications (WSDL and PDFs). Before designing your system, consult the technical section for limits, maximum payload sizes and retry or rate limit policies:

    • AEAT — SII technical documentation: https://sede.agenciatributaria.gob.es/Sede/iva/suministro-inmediato-informacion.html
    • SII service technical description (traffic and error details): https://sede.agenciatributaria.gob.es/staticfiles/Sede/Procedimientoayuda/G417/FicherosSuministros/V11/SII-Descripcion-ServicioWeb-v1-1eses.pdf

    If the technical manual does not specify an absolute limit, or publishes it elsewhere, design your architecture with queues and exponential backoff to avoid rejections and ask AEAT support for clarifications if needed.

    Proposed architecture and step‑by‑step flow using AI agents

    Below is a modular, non‑prescriptive flow we use as a baseline in the Momentum Process (audit, architecture, local deployment, integration and optimisation).

    Step 0 — design and pre‑requirements (data policy and scope)

    Minimum checklist before starting:

    • Define which invoice series and types you will automate (e.g. invoices to private customers vs invoices to the Administration).
    • Review cloud provider contracts and whether an HSM is required for key protection.
    • Retention policy and audit trail (logs of submissions, responses and retries).
    • Assess whether a DPIA is required (see GDPR section).

    Step 1 — extraction and enrichment with AI agents

    What an AI agent can do:

    • OCR and data extraction from received invoices.
    • Classification of line items and mapping to accounting accounts.
    • Pre‑fill required Facturae fields (always with subsequent validation).

    Recommended controls:

    • Validate extracted data with rules (for example: NIF pattern checks) and perform human sampling during the pilot.
    • Record the agent’s decision in the audit trail (proposed value, confidence and who or what confirmed it).

    Momentum experience — how we work in practice:

    At Momentum Logic AI we deploy in phases: first a sandbox pilot with integration tests and XSD validation, then a controlled production period with sampling and human checks agreed with the client, and finally full automation once accepted. During the pilot we run submission tests and review AEAT responses, documenting evidence (test files, logs and sampling decisions). These steps are part of our Momentum Process (technical audit, deployment and optimisation).

    Note: pilot scope (duration, sample size) is agreed with each client according to risk and volume.

    Illustrative example (hypothetical): a self‑employed sole trader (autónomo) issuing 30 invoices/month could automate extraction and pre‑fill in minutes; with automated validations you reduce manual rejection handling. (Hypothetical example; adjust percentages to your case.)

    If you would like help assessing your specific situation and what to automate first, we can review your use case and advise on a pragmatic pilot.

    Step 2 — Facturae XML generation and local validation

    • Map ERP fields to the mandatory XSD elements.
    • Run XSD and business‑rule validations (NIF, VAT codes, arithmetic sums, series). Log and correct errors before signing or sending.

    Step 3 — signing/sealing and preparation for submission

    Technical options:

    • Electronic signature with a qualified certificate or use of an HSM to protect keys.
    • Inclusion of a timestamp seal if required by the operation.

    Note: confirm in AEAT documentation whether delivery to SII requires signing the XML or whether channel authentication suffices: https://sede.agenciatributaria.gob.es/Sede/iva/suministro-inmediato-informacion.html. For VERI*FACTU‑specific requirements consult: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu.html

    If you prefer us to set this up with you, Momentum covers this phase during architecture and deployment.

    Step 4 — submission to SII / VERI*FACTU (or FACe when applicable) and handling responses

    Selection criteria:

    • Submit to SII when you are obliged to, or decide to supply VAT records.
    • Submit to FACe only when an invoice must be delivered to a public body as a supplier (FACe: https://proveedores.face.gob.es/).

    Operational flow:

    • Call the service (WSDL/web service) and persist the request with a unique correlation ID.
    • Process responses: accepted, pending, rejected. Implement retries with backoff and keep logs for accounting reconciliation.
    • Store the full trace (request, response, retry logs) for audit purposes.

    Practical integration: link this flow with your ERP/accounting system to flag states and reconcile entries automatically.

    You can also consult our guide on automating recurring invoicing and bank reconciliation to see how to connect this with accounting and reconciliation processes: our guide on automating recurring invoicing and bank reconciliation

    Testing, approval and go‑live

    • Use AEAT homologation/sandbox environments where available. Perform volume, latency and error‑case tests (invalid NIF, validation rejections, timeouts).
    • Document tests and keep dated evidence (files, logs, screenshots).
    • Define clear production acceptance criteria with your tax and technical teams (for example: percentage of files passing XSD validation, tolerance for retries, and load tests that reflect expected volume). Consult AEAT on formal homologation requirements if applicable: https://sede.agenciatributaria.gob.es/Sede/iva/suministro-inmediato-informacion.html

    Security, data protection and compliance (GDPR)

    Minimum checklist:

    • Carry out a DPIA where you process sensitive personal data or the automation changes the scale of processing.
    • Encrypt in‑transit (TLS) and at rest any databases holding invoices.
    • Role‑based access control and immutable logging for critical operations.
    • DPA/contractual arrangements with cloud providers and clauses on subprocessors when external AI services are used.
    • Avoid sending data to third‑party models without contract and technical guarantees. Record automated decisions and the human verification criteria.

    Operation, monitoring and operational limits

    Recommended metrics:

    • AEAT rejection rate (% of submissions rejected).
    • Average response latency per submission.
    • Mean time to resolution for rejections.
    • Retry rate and post‑retry success rate.

    Implement dashboards with alerts (for example, when rejection rate breaches an agreed threshold) and escalation procedures.

    Common errors and practical fixes

    • XSD validations: maintain a unit test suite with valid and invalid examples.
    • Misformatted NIF/CIF: validate with regex and the control digit where applicable.
    • Tax base mismatches: check arithmetic sums and rounding before sending.
    • Rate limit rejections: implement queuing and exponential backoff.
    • Authentication errors: verify certificates and expiry dates.

    For each error code, consult the SII technical manual for the precise meaning: https://sede.agenciatributaria.gob.es/staticfiles/Sede/Procedimientoayuda/G417/FicherosSuministros/V11/SII-Descripcion-ServicioWeb-v1-1eses.pdf

    Practical architecture example (simplified fictional case)

    Minimum suggested architecture (example):

    • UI/ERP -> AI agent (OCR + classification) -> Facturae validator (XSD + rules) -> Signing/HSM -> SII submission -> Recording and reconciliation.

    Responsibility table (hypothetical example):

    • ERP: commercial and client data.
    • AI agent: extraction and pre‑fill.
    • Validator: XSD and business rules.
    • Signing/HSM: key management and signing.
    • Submission component: calls to AEAT and retry handling.

    Pre‑deployment checklist:

    • XSD validation against the official version (Facturae portal).
    • Credentials for AEAT sandbox access.
    • Load tests that represent realistic peaks.

    TABLE: PAST / PRESENT / FUTURE (reference 09/09/2026)

    Period Summary Source / note
    PAST Initial SII roll‑out and publication of the first resolutions and orders related to its implementation in the late 2010s; Facturae already existed as the official electronic invoicing format for Administration submissions. Regulations and orders published in the BOE — consult the BOE for historic orders and resolutions: https://www.boe.es/
    PRESENT (09/09/2026) The AEAT maintains SII technical documentation and offers applications such as VERI*FACTU; there are portals for Facturae and FACe. The exact scope of obliged entities must be checked on the AEAT electronic office. https://sede.agenciatributaria.gob.es/Sede/iva/suministro-inmediato-informacion.html (consulted 09/09/2026)
    FUTURE Announcements and analysis exist on VERI*FACTU evolution and potential changes to schemas or SII scope; any extension or future obligation dates must be confirmed via official AEAT or BOE resolutions. Check AEAT and BOE news and resolutions for updates (links under Official resources).

    Conclusion and recommended next steps

    Integrating Facturae and the SII into an automated flow with AI agents is feasible and brings efficiency, but you must verify schema versions, authentication methods, submission limits and any signing requirements before production. Practical next steps:

    • Verify the Facturae XSD and download the current version from: https://www.facturae.gob.es/
    • Confirm WSDL/web services and authentication methods in the AEAT SII technical manual: https://sede.agenciatributaria.gob.es/Sede/iva/suministro-inmediato-informacion.html
    • Obtain credentials and test in the AEAT sandbox where available.
    • Perform a DPIA if required and finalise DPAs with your providers.
    • Run volume tests and define acceptance metrics.

    If you would like us to evaluate your specific case, request a Free Assessment and we will advise which parts to automate first.

    Official resources (consulted / for verification)

    • AEAT — Suministro Inmediato de Información (SII): https://sede.agenciatributaria.gob.es/Sede/iva/suministro-inmediato-informacion.html (consulted 09/09/2026)
    • Facturae (official portal and schemas): https://www.facturae.gob.es/ (consulted 09/09/2026)
    • FACe — Central Entry Point for invoices: https://proveedores.face.gob.es/ (consulted 09/09/2026)
    • VERI*FACTU (AEAT): https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu.html (consulted 09/09/2026)
    • SII service technical description (AEAT PDF): https://sede.agenciatributaria.gob.es/staticfiles/Sede/Procedimientoayuda/G417/FicherosSuministros/V11/SII-Descripcion-ServicioWeb-v1-1eses.pdf
    • BOE (search resolutions and orders): https://www.boe.es/

    FAQs

    1. Who is currently obliged to use SII and how do I verify?
    • Check the list and resolutions on the AEAT SII electronic office; if unsure, consult your tax adviser.
    1. Is Facturae the same as SII or can I use FACe to meet SII obligations?
    • No. Facturae is the format; FACe is a portal to deliver invoices to the Administration; SII is the supply of VAT records to the AEAT. They are not interchangeable without checking applicable rules.
    1. What authentication methods does AEAT accept for SII services?
    • Exact methods and credential acquisition are documented in the AEAT technical section and service PDFs referenced above: https://sede.agenciatributaria.gob.es/Sede/iva/suministro-inmediato-informacion.html
    1. What checks should I run before sending automated invoices to SII?
    • XSD validation, business rules (NIF, bases, VAT), signing/sealing if applicable, sandbox tests and GDPR compliance.
    1. How do I ensure GDPR compliance when using AI agents for invoicing?
    • Perform a DPIA if required, encrypt data, set DPAs with providers, log automated decisions and keep human checks for sensitive operations.

    This article was drafted with the support of artificial intelligence and reviewed by qualified Momentum Logic AI staff before publication.

    Keep reading

  • Guide: Convert quotes to invoices and automate online payments

    Guide: Convert quotes to invoices and automate online payments

    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

    Keep reading

  • How to Automate Recurring Invoicing and Bank Reconciliation with AI

    How to Automate Recurring Invoicing and Bank Reconciliation with AI

    In this article you’ll find a practical, applied guide to automating recurring invoicing (generation, dispatch and recording) and bank reconciliation using solutions that incorporate AI, written for self-employed professionals operating in Spain (autónomos). I summarise what can be automated today, what requires human oversight and which legal and technical checks are essential.

    I will cover:

    • Legal and data-protection requirements you should verify (official links below).
    • Recommended technical architecture by layers and the key components.
    • Practical steps to implement it (rollout template and control checklist).
    • How to choose vendors and the right questions to ask about AI and security.
    • Risks, controls and a step‑by‑step illustrative example.

    Verified as of: 31/08/2026. Any time‑sensitive legal or product details should be reconfirmed with the official sources cited at the end before making decisions.

    Quick summary: can you automate everything, and what to really expect?

    Automating recurring invoicing and bank reconciliation with tools that use AI is largely feasible today, but it does not fully replace human review. Routine tasks — generating invoice templates, automated dispatch by email or to public platforms where applicable, capturing payments from gateways and rule‑based matching — are already automated by many platforms.

    AI capabilities (ML/NLP) are used to classify receipts, resolve uncertain matches and extract information from transaction descriptions, but accuracy and responsibilities vary by vendor and must be verified on a case‑by‑case basis.

    Concrete use cases:

    • Periodic subscription invoices: automated generation and sending, integration with a payment gateway and marking invoices as paid once a payment is reconciled.
    • Automated payment reminders and escalation (email/SMS) under configurable rules.
    • Automatic reconciliation of bank movements with invoices using rule‑first logic and AI models for uncertain matches.

    Current limits: AI suggests matches and classifications; final accounting entries and material tax decisions require human oversight. In addition, obligations such as document retention, legal bases for processing banking data and requirements related to SCA/PSD2 may impose extra controls. The EU General Data Protection Regulation (GDPR) applies to processing banking data; consult the official text: Reglamento (UE) 2016/679 (RGPD).

    Benefits and expected returns from automating invoicing and reconciliation with AI

    Direct benefits:

    • Time saved on repetitive tasks (issuing, sending and initial matching).
    • Fewer manual errors in posting and classification.
    • Better cash‑flow control and near‑real‑time reporting.
    • Fewer delays in collections thanks to reminders and automated recurring payments.

    Indirect benefits:

    • Reduced workload for your accountant or gestoría, allowing focus on higher‑value work.
    • Improved documentary compliance if the system keeps logs and traceability.

    Important nuance: do not publish percentage savings or accuracy claims without vendor documentation. Request verified metrics before assuming quantitative expectations.

    Illustrative example (indicative only):

    • Before: María, a freelance designer, spent 4 hours a month generating invoices and 6 hours reconciling manually; of 50 transactions, 8 needed manual review.
    • After (rules + AI): generation and sending are automated; rules reconcile approximately 80% automatically and AI suggests matches for 15%; María then reviews only 5–6 cases. (Illustrative example; not a guarantee of results.)

    Regulation, privacy and tax obligations (past / present / future)

    Note: this section is time‑sensitive. For any legal or tax decision consult the official sources referenced below (AEAT, BOE, AEPD, EBA, Banco de España).

    Past (relevant milestones)

    • Regulation (EU) 2016/679 (GDPR) is the framework regulating personal data processing in the EU, including banking information. Source: EUR-Lex (RGPD).
    • In Spain there is the Facturae format and the FACe portal for invoices to public administrations. Source: Facturae / FACe.

    Present (status at reference date)

    • There is variability in the availability and functionality of open banking APIs among institutions and in the aggregator market; PSD2 and the EBA technical standards on SCA are relevant for payments and access. Consult the Bank of Spain and the European Banking Authority for the regulatory status applicable to access and strong authentication: Banco de España and EBA.

    • The concrete scope of the Suministro Inmediato de Información (SII) for your specific case must be checked with the Spanish Tax Agency: SII – AEAT and, where applicable, in the BOE for official regulatory texts: BOE. Do not generalise the obligation: applicability depends on the status of the taxpayer (type of activity, volume, etc.).

    • For processing banking data verify the legal basis (consent, contract, legitimate interest) and, if needed, carry out a Data Protection Impact Assessment (DPIA). Consult the Spanish Data Protection Agency guides: AEPD.

    Future (trends to watch)

    • Greater adoption of Open Banking and near‑real‑time reconciliation capabilities is likely, but any change in obligations or deadlines should be confirmed via official releases from the Ministry of Finance / AEAT, EBA or Bank of Spain.

    Recommended technical architecture for self‑employed professionals

    Layered proposal:

    1) Invoice generation layer

    • Templates (PDF/UBL/Facturae) and a generation engine (API or UI).
    • Minimum requirements: recurrent templates, customisable fields and the ability to export XML Facturae when required.
    • Risk: using non‑compliant Facturae versions; CHECKLIST: verify version and XML validation.

    2) Delivery layer

    • Send by email with tracking, submit to public platforms (FACe) or via SII/API if applicable to your case.
    • Requirements: support for Facturae/UBL and delivery receipts.

    3) Payment layer

    • Integration with payment gateways (card/SEPA/direct debit) and management of recurring collections.
    • Requirements: compliance with SCA/PSD2 for certain charges (consult applicable rules at EBA/Bank of Spain).

    4) Bank feed aggregation layer

    • Open Banking connectors (API) or aggregators that normalise bank statements.
    • Requirements: clarify access method (API vs screen scraping), OAuth/SCA and credential retention policies.

    5) Reconciliation engine (rules + AI)

    • Hybrid engine: deterministic rules first (exact amount, invoice reference), ML/NLP for uncertain matches.
    • Requirements: traceability, model versioning and the ability to correct rules.

    6) Control and audit layer

    • Human review panel, change logs, exportable accounting entries and backups.
    • Requirements: export to accounting formats and log retention according to applicable tax rules (consult AEAT/BOE).

    Suggested diagram (summary):
    [Invoice input] → Generator (template/XML) → Delivery/registration (FACe/SII) → Payment (gateway) → Bank aggregator (API/OAuth) → Reconciliation engine (rules → AI → human review) → Accounting entry/report.

    If you would like us to build this for you, in the Process Momentum architecture phase we can design the integrations, define rules and controls. (Contact and terms depend on scope.)

    Key components and how they work (detail)

    • Invoice generator: create recurring invoices in a fiscally valid format. Technical requirements: XML/Facturae export, templates and API triggers.
    • Delivery/registration: deliver invoices to customers and/or the administration; requirements: delivery receipts and logs.
    • Bank aggregator / Open Banking connector: obtain movements and balances. REQUIREMENT: ask the vendor how they access accounts (API preferred vs screen scraping) and how they manage credentials.
    • Reconciliation engine: configurable rules + ML for uncertain matches; CHECKLIST: request decision logs and the ability to revert.
    • Control/audit layer: ensure traceability and keep logs for the period required by tax rules (consult AEAT/BOE).

    How reconciliation with AI works: techniques and critical points

    Typical techniques:

    • Rule‑based matching (amount, reference).
    • ML models for uncertain matches with a confidence score.
    • NLP to parse transaction descriptions.
    • Confidence scoring and a human‑review flow when confidence is low.

    Metrics to request from a vendor (ask for evidence):

    • Percentage of movements automatically matched (automatic reconciliation rate).
    • False positive/negative rates (precision/recall) of the ML engine.
    • Average time to resolve pending cases.
    • Decision logs and the ability to audit models.

    Do not accept accuracy claims without technical evidence (whitepaper, audit or verifiable metrics).

    Choosing vendors and evaluation criteria

    Checklist of criteria:

    • GDPR/AEPD compliance and data location.
    • Type of bank access: API (preferred) vs screen scraping — request documentation.
    • Evidence of AI use: technical documentation, whitepaper or tests.
    • SLA, liabilities and coverage for reconciliation errors.
    • Security: SCA, encryption in transit and at rest, external audits.
    • Exportability and accounting compatibility (CSV/Facturae).
    • Support, cost and integrability with your gestoría.

    Key contractual questions to ask a vendor:

    1. How do you access bank accounts (direct API, aggregator, screen scraping)?
    2. Do you retain customer credentials? If so, how are they protected and for how long?
    3. What is the legal basis for processing banking data in my case (consent, contract)?
    4. Which performance metrics for the AI engine can you provide (precision/recall, automatic reconciliation rate)? Request evidence.
    5. Do you have a whitepaper or technical documentation for the AI model used?
    6. How do you record and audit changes to rules and models?
    7. What SLAs do you offer for availability, response times and support?
    8. How do you ensure data exportability and compatibility with Facturae/my gestoría?
    9. What contractual responsibilities do you accept in case of an accounting error caused by the tool?
    10. Do you comply with GDPR and hold certifications or external audits?

    Implementation step‑by‑step for a self‑employed professional (actionable checklist)

    Phases and tasks (checkbox style):

    • Preparation

    • [ ] Review tax obligations and document retention with your advisor and consult AEAT/BOE about SII applicability: SII – AEAT.

    • [ ] Select a vendor that complies with GDPR and offers exportable accounting data.

    • [ ] Define your catalogue of recurring invoices and templates.

    • [ ] Document flows and internal responsibilities.

    • Pilot (estimated 4–6 weeks, indicative)

    • [ ] Configure 1–2 recurring billing cycles.

    • [ ] Connect a bank account in test mode and validate access.

    • [ ] Define priority reconciliation rules.

    • [ ] Measure automatic reconciliation rates and errors (request evidence from the vendor).

    • Rollout (cutover week)

    • [ ] Enable recurring invoicing in production.

    • [ ] Set reconciliation schedule (daily/weekly).

    • [ ] Backup and rollback protocols in case the vendor fails.

    • Operation and governance

    • [ ] Periodic review (monthly) of manual cases.

    • [ ] Audit logs and review rules/model adjustments.

    • [ ] Backups and document‑retention plan according to the applicable rules.

    Estimated roll‑out template (6–8 weeks indicative):

    • Week 1–2: Select and sign with vendor; define templates.
    • Week 3–4: Technical integration and test setup; first test sends.
    • Week 5: Reconciliation pilot in a controlled environment.
    • Week 6–7: Rule tuning and user training.
    • Week 8: Production go‑live and initial review.

    (These times are indicative; request a detailed plan from your vendor tailored to your volume.)

    Practical worked example (mini case, illustrative)

    Illustrative scenario: Juan, a self‑employed web‑maintenance provider, invoices 40 clients monthly subscriptions of EUR 50.

    1. Generation: he configures monthly templates with automatic numbering and PDF + XML Facturae.
    2. Delivery: he activates automatic email dispatch and sends a copy to his gestoría.
    3. Payment: he integrates a SEPA gateway or direct debit.
    4. Aggregation: he connects the bank account via an aggregator API (if the bank allows).
    5. Reconciliation: rules automatically match direct debits to invoices by amount and reference; AI suggests matches when the transaction description differs.
    6. Review: every two weeks Juan reviews low‑score cases in the panel and approves accounting entries.

    Illustrative outcome: less monthly time reconciling and fewer posting errors; always with human intervention for material entries.

    Costs, grants and return on investment

    Cost components to consider:

    • Software licence / monthly subscription or per‑transaction fee.
    • Aggregator fees or connection charges.
    • Integration and development costs.
    • Maintenance and support.

    Grants and aid: there are digitalisation programmes for SMEs and self‑employed professionals; check calls on Red.es and relevant regional portals before assuming eligibility: Red.es.

    ROI model (no concrete figures provided):
    Inputs: monthly hours saved × hourly cost, monthly software cost, integration expenses.
    Basic ROI = (Monthly labour cost savings – monthly solution cost) / initial implementation cost (or amortisation in months).

    Risks and mandatory controls

    Principal risks and suggested controls:

    • Legal/tax risk: sending or posting incorrect invoices. Control: pre‑validation and human review.
    • Privacy risk: exposure of banking data. Control: insist on GDPR compliance and a processing clause; conduct a DPIA if appropriate (consult AEPD: AEPD).
    • Security risk: insecure access through screen scraping. Control: prefer API/OAuth and review credential retention policies.
    • Operational risk: reconciliation errors. Control: dual approval for critical entries, logs and easy reversal.

    Practical comparison template and legal text samples (note)

    Do not publish comparative claims without verifying each against vendor documentation. This version does not include downloadable templates: instead, use this example table to copy and compare vendors:

    • Fields: vendor | bank access type | AI evidence (yes/no + link) | accounting integration | Facturae exportability | SLA | estimated price | documentation link

    Legal/consent text (templates to adapt with your advisor):

    Consent for bank connection (base text):
    “I authorise [VENDOR_NAME] to access my bank account data for the exclusive purpose of obtaining statements and movements for the accounting reconciliation of my professional activity. Data will not be retained longer than strictly necessary and will be processed in accordance with the GDPR.”

    Privacy clause for invoicing (adapt with advisor):
    “Data provided for invoice issuance will be processed by [COMPANYNAME] as controller for the purpose of issuing and retaining invoices and complying with tax obligations. For more information and rights consult [PRIVACYPOLICY_LINK].”

    (Recommendation: adapt and validate with legal counsel. Consult AEPD guidance on information to data subjects and DPIA: AEPD.)

    Selected FAQs (summary)

    1) Can a self‑employed person automate recurring invoicing without breaching rules?

    • Generally yes, but check specific obligations with AEAT and BOE for your case (AEAT / BOE).

    2) What data‑protection obligations arise when using a bank aggregator?

    • Legal basis (consent or contract), technical measures and, if relevant, a DPIA (consult AEPD: AEPD).

    3) How does AI ensure reliability in bank reconciliation?

    • AI suggests matches with a confidence score; reliability depends on the model and training data. Request verifiable metrics from the vendor.

    4) Do I need my bank to provide APIs to reconcile automatically?

    • Not always: aggregators exist, though direct API access is usually preferable for security and stability. Check with your bank and integrator.

    5) Can I fund implementation with grants? Where to check?

    • Review calls and eligibility on Red.es and regional official portals before assuming eligibility (Red.es).

    6) How does SII affect invoice automation for self‑employed professionals?

    • SII changes timing and form for submitting VAT information; applicability depends on taxpayer status. Consult AEAT: SII – AEAT.

    Conclusion and recommended next step

    Automating recurring invoicing and bank reconciliation with AI is viable and brings time savings and better cash‑flow control, but it requires the right legal checks and operational controls. Recommended next step: run a controlled pilot with a GDPR‑compliant vendor that allows accounting exports.

    If you would like us to evaluate your specific case and recommend what to automate first, you can request a Free Assessment (consult conditions and scope).

    Legal notice and final recommendations

    This article does not constitute legal or tax advice. Consult the AEAT, BOE and your tax advisor before making decisions that affect tax obligations. For data‑protection matters consult the AEPD.

    Sources and official links cited in the text:

    This article was drafted with the support of artificial intelligence and reviewed by qualified Momentum Logic AI staff before publication.

    Keep reading

  • IRPF deduction for photovoltaic self-consumption 2026: guide for freelancers

    Many self‑employed people and small companies in Spain are considering photovoltaic panels: they reduce the electricity bill and can also give access to tax deductions. The frequent difficulty is that rules change often and the concrete conditions (percentage, limit, documentary requirements) vary by type of taxpayer and by autonomous community. In this article I explain, in clear language and with a practical example, how to calculate an IRPF deduction for investment in self‑consumption for the 2026 tax return and which steps to follow so you do not make avoidable mistakes.

    I will not invent percentages or new rules: where appropriate I point to the current legislation and to the official sources you should consult.

    What is the “deduction for self‑consumption” in practical terms?

    Broadly speaking, a deduction for photovoltaic self‑consumption is a fiscal benefit that reduces the tax burden linked to the investment in a solar installation. In practice this means that part of the cost you incurred for the installation can be applied as a deduction on the IRPF return of a self‑employed person who uses the installation in their professional activity or in their home.

    The specific conditions (which percentage applies, whether there is a maximum cap, whether the deduction is taken in a single year or spread over several years, compatibility with grants, etc.) depend on state and autonomous community rules. For official information consult the Agencia Tributaria and the competent regional authorities. Useful guides and resources:

    • Agencia Tributaria (information on deductions related to energy efficiency and works): https://sede.agenciatributaria.gob.es/Sede/vivienda-otros-inmuebles/deducciones-obras-mejora-eficiencia-energetica-viviendas/deduccion-obras-mejora-consumo-energia-renovable/base-porcentaje-deduccion.html
    • IDAE (technical guides and self‑consumption procedures): https://www.idae.es/publicaciones/guia-profesional-de-tramitacion-del-autoconsumo
    • BOE (legislation and royal decrees related to self‑consumption incentives): https://www.boe.es/buscar/act.php?id=BOE-A-2021-10824

    If you need to check how your autonomous community regulates requirements and grants, consult the regional administration website (examples given in the Spanish version):

    • Comunitat Valenciana (example of regulations/authorisations): https://www.gva.es/es/inicio/procedimientos?id_proc=21988
    • Junta de Andalucía — Autoconsumo: https://www.juntadeandalucia.es/organismos/universidadindustriaenergiaeinnovacion/areas/energia/autoconsumo.html

    Important note: there is no single national “rate” that applies uniformly to all self‑consumption deductions in 2026. The AEAT (Agencia Tributaria) regulates deductions linked to energy efficiency, and some autonomous communities add complementary deductions or specific requirements. Therefore, before filing your return, confirm your specific case with the AEAT and the relevant regional administration.

    Requirements and documentation (what you must keep)

    To justify the deduction to Hacienda it is advisable to gather and retain at least the following:

    • Original invoice for the installation (itemised: materials, labour, technical design if applicable).
    • Proof of payment (bank transfer, receipt, etc.).
    • Installer certificate or authorised document proving installed capacity and technical conditions.
    • Communication or registration in the regional or municipal installations registry, if applicable (check the regional website).
    • Resolutions or certificates of public grants received (if any).
    • Calculation of the professional use share versus private use (explained below).
    • Technical report or project if the rule requires it because of installed capacity.

    Bear in mind: some requirements are regional or municipal; confirm what applies in your territory by consulting the guidance published by your autonomous community (see IDAE and the regional links above).

    How to calculate the deduction: clear steps

    Below is a step‑by‑step method you can apply with your own numbers. Where legal values are needed (percentages, caps, years of application) this article directs you to official sources instead of asserting a single figure.

    1) Determine the eligible investment base

    • Baseinvestment = Totalinstallationcost – Publicgrants_received

    Include in the total cost everything invoiced for the installation (materials, equipment, labour, project). Subtract grants or incentives you have received: frequently the deduction applies to the net amount you actually bore, but confirm the specific treatment with the AEAT and the regional rules.

    2) Check the applicable deduction percentage

    • %deduction = percentage set by the rule applicable to your case (consult the AEAT and the autonomous community legislation)

    There is not a single national “%deduction” that fits all cases: the Agencia Tributaria publishes rules for deductions related to energy efficiency and regional administrations can set complementary deductions.

    3) Apportion by professional use (if applicable)

    If the installation is used entirely for the professional activity (for example, a workshop that consumes all produced energy), 100% of the investment may be eligible. If it is shared between business use and domestic use, you must allocate the portion attributable to the activity.

    Practical method to prorate:

    • Record a representative period (e.g. 3 months) of energy generated and energy consumed by the professional activity.
    • %professionaluse = kWhconsumedinactivity / kWhtotalgenerated

    If you cannot measure kWh directly, you can use reasonable criteria (area dedicated to the activity, machine operating hours, etc.) and document the methodology.

    4) Calculate the theoretical deduction

    Basic formula:

    • Theoreticaldeduction = Baseinvestment × %deduction × %professional_use

    Example form: Deduction = (Cost − Grant) × %deduction × %professional_use

    5) Annual limits and application in the tax return

    The treatment (annual cap, ability to apply the deduction over several years, whether it reduces IRPF liability in the year of execution or acts as a tax credit carried forward) depends on the rule applicable to the particular deduction. Check the AEAT and regional legislation to know:

    • whether there is an annual ceiling or a global limit,
    • in which tax years the deduction can be claimed,
    • whether the deduction is set against tax due in the year of execution or functions as a credit for later years.

    Reference sources: the AEAT publishes guides and manuals on deductions and tax periods; also check the corresponding regional legislation.

    Illustrative example (hypothetical)

    This example is hypothetical and uses percentages illustratively; legal percentages must be checked in the cited sources.

    Situation: Marta is self‑employed (a repair workshop) and installs a 6 kW photovoltaic system in her unit that costs EUR 7,500. She receives a municipal grant of EUR 1,500. She estimates, from measurements and typical consumption, that 60% of the energy generated is used for her professional activity.

    Suppose (HYPOTHETICAL — not a legal figure) that the allowed deduction were 20%.

    Calculation:

    • Base_investment = EUR 7,500 − EUR 1,500 = EUR 6,000
    • %deduction = 20% (HYPOTHETICAL — confirm with AEAT/regional rules)
    • %professional_use = 60% (0.6)

    Theoretical_deduction = EUR 6,000 × 0.20 × 0.6 = EUR 720

    Interpretation: in this example Marta could apply EUR 720 as a deduction on her IRPF provided the rule applicable to her case in 2026 allows that percentage, that base treatment and that temporal allocation. If the deduction cannot be consumed in a single year because of insufficient tax liability, you should check the compensation or carry‑forward rules (consult the AEAT and the regional legislation for exact treatment).

    Practical checklist before filing

    • [ ] Itemised invoice for the installation
    • [ ] Proof of payment matching the invoice
    • [ ] Installer certificate or technical document proving the installation
    • [ ] Evidence of grants or aid received
    • [ ] Registration or communication to the regional/municipal body (if applicable)
    • [ ] Documented calculation of the % professional use (measurements or reasonable criteria)
    • [ ] Consult your tax advisor about accounting treatment (fixed assets, amortisation, etc.)

    Common mistakes and practical recommendations

    • Failing to justify the % professional use: arbitrary allocations without support are often flagged in inspections.
    • Forgetting to subtract grants from the investment base: many deductions require a net base (check the applicable rule).
    • Overlooking mandatory communications or registrations in the autonomous community: these can condition the deduction’s validity.
    • Not coordinating with your tax advisor: the accounting treatment (recording as fixed assets, applying amortisation) affects the final outcome and must align with the deduction.

    Practical tip: before you carry out an installation, do an energy and tax audit. At Momentum Logic AI we include the audit and technical architecture phase so you know from day one which part of the investment will be fiscally deductible and how to integrate it in accounts and business processes.

    How Momentum Logic AI supports the process

    Our Momentum Process — audit, architecture, local deployment, integration and optimisation — is designed so the installation not only performs well technically but that its documentation and monitoring also make it easier to apply fiscal benefits:

    • Audit: we measure consumption and propose the right capacity to maximise self‑consumption.
    • Architecture: we design the system with documentary traceability and billing in mind.
    • Local deployment and integration: we coordinate installers and monitoring tools to record kWh and justify the % professional use.
    • Optimisation: we help ensure the installation operates in ways that improve fiscal and operational returns.

    If you wish, we can start with a Free Assessment to review your specific case and prepare the necessary documentation (commercial proposal required for contracted services; no guaranteed tax outcome is promised).

    Conclusion

    Calculating the IRPF deduction for photovoltaic self‑consumption in 2026 essentially means applying the legal deduction to the net investment base and apportioning it for professional use. However, practical details (percentages, caps, allowed years, documentary requirements) depend on current legislation and your particular situation. Before you file, confirm the applicable percentages and limits for 2026 with the Agencia Tributaria or your tax adviser and keep all technical and administrative documentation.

    This article was drafted with the support of artificial intelligence and reviewed by qualified Momentum Logic AI staff before publication.

    Keep reading