Momentum Logic AI Blog

Author: Equipo Momentum Logic AI

  • How to calculate Kit Digital ROI: practical guide for SMEs

    How to calculate Kit Digital ROI: practical guide for SMEs

    In this guide you will find a clear formula to calculate the Kit Digital ROI, which costs and benefits to include, practical examples by category (e‑commerce, CRM/ERP, cybersecurity…) and a template you can copy into Excel or Google Sheets. Note: amounts and the opening of calls change quickly; always check the Sede Electrónica de Red.es and the BOE before making decisions.

    Quick summary: ROI formula and practical steps in 60 seconds

    Common basic formula:

    • Simple ROI = (Net benefit − Net cost) / Net cost
    • Alternative (more compact): ROI = Net benefit / Net cost

    Where “Net cost” for projects supported by the Kit Digital is usually understood as: total project invoice − subsidised amount (only if the aid has actually been granted and justified) + any recurring costs you decide to include in the chosen evaluation horizon.

    Quick checklist to calculate it:
    1) Set the evaluation horizon (1, 3 or 5 years).
    2) Calculate net initial investment = total invoice − subsidised amount (if granted).
    3) Add implementation costs, training and annual recurring costs (hosting, subscription, support).
    4) Estimate annual benefits (additional revenue and monetised savings).
    5) Calculate ROI and payback.

    Mini illustrative example (hypothetical):

    • Net initial investment: EUR 6,000
    • Savings and additional revenue year 1: EUR 3,000
    • ROI year 1 = (3,000 − 6,000) / 6,000 = −0.5 (−50%) — indicates payback > 1 year.

    PAST / PRESENT / FUTURE of the programme and what you must check before calculating ROI

    Practical orientation: the Kit Digital has been launched in calls since 2021 and has seen successive resolutions and annexes that set bands and requirements. Calls, annexes and conditions vary over time; before assuming a “voucher” amount or an Anexo IV value you must check the specific call applicable on the Sede Electrónica de Red.es and in the BOE. Do not assume a call is open without verifying those sources.

    To avoid errors when transferring amounts to your spreadsheet, always consult the Anexo IV of the applicable call (if relevant) on the Sede Electrónica de Red.es.

    Which costs to include when calculating ROI for supported projects

    Always include the following blocks:

    • Net initial investment (total invoice − subsidised amount). The grant reduces the net cost only if it has been granted and justified.
    • Implementation costs: configuration, data migration, integrations, internal staff time.
    • Training: hours of training per person × hourly rate.
    • Annual recurring costs: SaaS subscriptions, hosting, maintenance, licences, upgrades.
    • Cost of the digital agent: commissions or professional services outside the solution invoice.
    • Opportunity cost: internal resources diverted from the business (for example, owner/employee hours allocated to the project).
    • Indirect costs: periods of reduced productivity during rollout and process adaptation.

    How to calculate net initial investment (breakdown example)

    Practical formula:

    • Net initial investment = Total solution invoice + implementation costs + training − subsidised amount (if applicable and granted).

    Illustrative example (hypothetical):

    • Platform e‑commerce invoice: EUR 10,000
    • Implementation and migration: EUR 2,500
    • Training (10 hours at EUR 30/h): EUR 300
    • Subsidy granted (illustrative example): EUR 6,000
    • Net initial investment = 10,000 + 2,500 + 300 − 6,000 = EUR 6,800 (illustrative example).

    Remember: always mark the subsidised amount and keep the grant resolution as supporting evidence.

    If you prefer us to set this up with you, during the architecture phase of the Momentum Process we review the breakdown and validate which costs you should allocate. (soft assistance offer)

    Which benefits to account for (and how to estimate them)

    Direct benefits that can be monetised:

    • Sales increase: (traffic × conversion rate × average ticket) before and after.
    • Hours saved: hours/person saved × hourly cost.
    • Reduction in operating costs: less paper, fewer calls, fewer errors.
    • Costs avoided from incidents (in cybersecurity): estimate of losses avoided.

    Indirect or intangible benefits (document these, but value them cautiously): improved customer service, higher satisfaction, brand value, regulatory compliance.

    How to monetise hours saved (practical method):

    • Annual hours saved = (manual task hours/month × 12 × % automation).
    • Monetary saving = Annual hours saved × average hourly cost of the profile that performed the task.

    Suggested approach: model scenarios at 1, 3 and 5 years. To compare results you can annualise benefits or calculate a cumulative flow.

    Formulas to annualise benefits:

    • Average annual benefit = (Benefit year 1 + … + Benefit year N) / N
    • Annualised ROI = Average annual benefit / Initial net cost

    Metrics and time horizon: how to choose evaluation period and relevant KPIs

    The horizon depends on the solution: marketing and e‑commerce solutions typically show impact earlier (1–2 years); cybersecurity or BI may justify evaluations at 3–5 years. These are indicative orientations; adjust to your company reality.

    Quick template (category → KPIs → recommended horizon):

    • E‑commerce: traffic, conversion rate, average ticket, CAC (cost per acquisition) → 1–2 years.
    • CRM/ERP: hours saved per process, lead-to‑close rate, sales cycle time → 1–3 years.
    • Cybersecurity: downtime avoided, estimated cost per incident, compliance level → 3–5 years.
    • Marketing/automation: CPL (cost per lead), conversion rate, LTV (customer lifetime value) → 1–2 years.
    • Invoicing and BI: time to close accounts, errors avoided, faster decisions → 1–3 years.

    Practical calculation by category: illustrative examples

    Note: the following examples are indicative estimates and are presented as hypothetical illustrations.

    E‑commerce (web presence and online store)

    What to include: platform cost, gateways, commissions per sale, implementation, initial marketing.
    Measurable benefits: increased conversions, higher average ticket, reduced abandonment.
    Quick formula: Revenue increase = traffic × (convrateafter − convratebefore) × average_ticket.

    Illustrative example:

    • Current monthly traffic: 5,000 visits
    • Current conversion rate: 1%
    • Expected conversion rate after improvements: 1.5%
    • Average ticket: EUR 50
    • Monthly increase = 5,000 × (0.015 − 0.01) × 50 = EUR 12,500 / month → EUR 150,000 / year (illustrative).
    • Translate this into ROI by comparing annual revenue increase against net cost.

    CRM / ERP (customer and process management)

    What to include: licence, implementation, integrations, training.
    Benefits: hours saved in administrative tasks, better lead conversion.

    Illustrative example based on hours:

    • Administrative tasks: 400 h/year that can be reduced by 40% → 160 h/year saved.
    • Average hourly cost: EUR 25 → annual saving = 160 × 25 = EUR 4,000 (illustrative).

    Cybersecurity

    How to value it: usually measured as risk reduction. Practical technique: estimate expected loss = incidentprobability × incidentcost.

    Illustrative example:

    • Annual probability before: 20% (0.2)
    • Average incident cost: EUR 20,000
    • Expected loss before = 0.2 × 20,000 = EUR 4,000
    • After improvements: probability 5% → expected loss = 0.05 × 20,000 = EUR 1,000
    • Estimated benefit = EUR 3,000 / year (illustrative).

    Warning: quantifying incident probability and cost is imprecise; document your assumptions.

    Digital marketing and automation

    Measure by CPL, CAC and LTV. Automation reduces cost per lead and speeds up nurturing.

    Illustrative example:

    • Current cost per lead: EUR 20; with automation it falls to EUR 15
    • Monthly leads 100 → monthly saving = 100 × (20 − 15) = EUR 500 → EUR 6,000 / year (illustrative).

    Electronic invoicing, cloud and BI

    Benefits: less time on administrative processes, faster close, fewer errors.

    Illustrative example:

    • 2 employees spent 10 h/month on manual tasks; automation reduces to 4 h/month → total annual saving = (2 × (10 − 4) × 12) × hourly_cost.

    Practical tools: spreadsheet template (copy to Excel/Google Sheets) and filled example

    Below is a minimal template to copy into a spreadsheet. Create columns by year up to your chosen horizon (e.g. 1–5) and replace values.

    Basic template (row per concept):

    • Initial investment: solution invoice
    • Implementation costs
    • Training
    • Subsidy granted (put 0 if not applicable)
    • Net initial investment (formula: sum all − subsidy)
    • Annual recurring costs (row per year)
    • Annual benefits (row per year)
    • Annual ROI = Annual benefit / Net initial investment
    • Payback period = Net initial investment / Annual benefit (if benefit>0)

    Filled example (hypothetical and simplified):

    • Net initial investment: EUR 6,800
    • Benefit year 1: EUR 3,000
    • Benefit year 2: EUR 6,000
    • Benefit year 3: EUR 6,500
    • ROI year 1 = 3,000 / 6,800 = 0.44 (44%)
    • Approximate payback ≈ 6,800 / 6,000 = 1.13 years (using average benefit years 2–3)

    Usage instructions: copy these rows into Excel or Google Sheets, enter your real figures and create formulas to sum and divide. Keep a column for assumptions and another for source documents.

    Limitations, risks and administrative and tax checks that affect ROI

    Key administrative risks:

    • Only accredited digital agents may manage the aid; verify accreditation on the Sede Electrónica de Red.es.
    • The grant reduces net cost only after it has been granted and correctly justified; there is a risk of repayment if documentation is not compliant.
    • Keep invoices, contracts, payment receipts and installation records; these documents are requested during audits.

    Checklist of documents to keep:

    • Invoice for the solution and for the digital agent.
    • Contract with the accredited digital agent.
    • Grant resolution and proof of receipt.
    • Implementation and training report (minutes/signatures).

    Tax considerations: the tax treatment of the received amount depends on current tax rules and the circumstances of each company. Consult your tax adviser or the Agencia Tributaria for your specific case.

    How to present the ROI calculation to a digital agent, bank or auditor

    Recommended one‑page structure:

    • Executive summary (1–2 sentences): project objective and summary of expected results.
    • Key assumptions: horizon, growth assumptions, conversion rate, hourly cost, incident probability (if applicable).
    • Calculation (tables): net investment, annual recurring costs, annual benefits, ROI and payback.
    • Sensitivity: three scenarios (pessimistic/realistic/optimistic) showing impact on ROI.
    • Attached documentation: invoices, contract with the agent, grant resolution.

    Always include a separate sheet with the formulas used and references for the assumptions.

    Frequently asked questions

    1) How is the Kit Digital subsidy incorporated in the ROI calculation?

    • A: Subtract the subsidised amount from the initial investment (total invoice). The subsidy only reduces net cost if it has been granted and justified officially. Check the grant resolution on the Sede Electrónica de Red.es.

    2) Can I treat the voucher amount as income in my accounts when calculating ROI?

    • A: We do not provide accounting/tax treatment in this article. Treatment depends on tax rules and your accounting: consult a tax adviser or the Agencia Tributaria for your case.

    3) Which recurring costs should I include?

    • A: SaaS subscriptions, hosting, maintenance, licences, support and any annual cost related to the solution.

    4) What documentation must I keep to justify the voucher to Red.es?

    • A: Invoices, contracts with the accredited digital agent, proofs of payment, implementation and training report, and the grant resolution.

    5) How long until I see ROI from an e‑commerce financed with public support (typical horizon)?

    • A: As an illustration, many online shops see impact between 6 and 18 months depending on marketing spend and business maturity; this is an estimate and varies by sector and case.

    6) What happens if there is a repayment of the aid: how does it affect the ROI calculation?

    • A: If there is a repayment, the net cost increases by the repaid amount and a previously positive ROI can turn negative. Keep all documentation and seek advice if you receive a requirement.

    Conclusion

    Public aid can substantially reduce the initial cost, but it does not by itself guarantee a positive ROI: project quality, assumptions, recurring costs and correct administrative justification matter. Start by defining horizon and KPIs, monetise savings and sales, and build scenarios to measure sensitivity.

    Request a Free Assessment: in a Free Assessment we review your situation and propose a realistic implementation plan and ROI calculation adapted to your SME. This is offered as guidance and does not promise guaranteed results.

    Official quick reference sources:

    • Kit Digital page at Red.es: https://www.red.es/
    • Sede Electrónica de Red.es (calls and Annexes): https://sede.red.gob.es/
    • Boletín Oficial del Estado (BOE): https://www.boe.es/

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

    Keep reading

  • Create and Automate a 30‑Day AI Content Calendar for SMEs

    Introduction

    Building a content calendar that actually works — and automating much of the process with AI — is one of the most practical ways for an SME or self‑employed professional (autónomo) in Spain to save time and keep a consistent brand voice. This guide gives you an actionable 30‑day pilot: an operational CSV template you can copy straight into Google Sheets, suggested automation flows for Zapier/Make/n8n, reusable prompts, mandatory human checks and legal recommendations. The figures and deliverables shown are illustrative and must be adapted to your specific situation.

    Reader profile and practical constraints

    This is aimed at a marketing lead or an SME owner with basic digital marketing knowledge who needs a clear, hands‑on plan. Estimated timeframe: operational pilot in 30 days. Indicative cost: low/medium if you rely on freemium tools and internal work; medium/high if you buy enterprise APIs or hire an agency. Always verify current prices and terms of service with each provider on their official website before purchasing.

    Legal notice and verification

    This article provides operational guidance. For legal obligations, entry dates of regulation, public grants or contractual conditions consult the official sources (EUR‑Lex, BOE, Red.es, AEPD, EDPB) and the documentation of any provider you intend to hire. Where legal checks are required we mark recommendations as indicative and tell you where to verify them.

    Summary of the 30‑day plan (what to accomplish each week)

    Week 1 — Strategy and setup

    • Objective: define content objectives, pick channels and configure accounts/credentials.
    • Deliverables (indicative): master calendar (30‑day template filled), list of integrations (API keys) and prompt templates.
    • Automated vs manual tasks: Automatable — initial ideation and draft generation with AI. Manual — final approvals and mandatory legal checks.

    Week 2 — Generation and testing

    • Objective: generate drafts and assets (text and images) and test prompts.
    • Deliverables (indicative): ~15 drafts ready for review, ~10 images/visuals generated (if applicable).
    • Human control: copy review, tone adjustment and fact‑checking (mandatory).

    Week 3 — Automation and scheduling

    • Objective: build flows in Zapier/Make/n8n that move drafts into your publishing tool.
    • Deliverables (indicative): active flows in sandbox, ~10 posts scheduled in a scheduler (eg Buffer/Loomly).
    • Pre‑go live: test checklist and rollback plan.

    Week 4 — Monitoring and optimisation

    • Objective: measure early performance and refine prompts, rules and timeslots.
    • Deliverables (indicative): first report with metrics, list of improvements and scaling plan.

    Mini deliverable table by week

    • Week 1: 30‑day template completed (manual/AI assisted)
    • Week 2: ~15 drafts and ~10 images (AI)
    • Week 3: ~10 scheduled posts (automation)
    • Week 4: dashboard with metrics and one optimisation cycle (human+AI)

    Mandatory human checkpoints: legal review (for example transparency obligations under applicable rules), fact‑checking and final brand control.

    Detailed template: 30‑day content calendar (CSV included)

    Below is the CSV template (comma separated). Copy and paste into a text editor or Google Sheets. Each row is a single publication and the column “automatizable” indicates whether the action can be automated or requires human review.

    CSV (separator “,”) — copy and paste into an editor/Google Sheets:

    fecha,canal,tipocontenido,objetivo,briefprompt,iagenerator,estadoqa,copyfinal,imagenurl,programador,metricasesperadas,automatizable,comentarioslegales
    2026-09-01,instagram,post,awareness,”Genera 3 ideas de copy friendly para un e‑commerce local de productos gourmet. Tonalidad: cercana, 100-150 caracteres.”,openai/gpt-4o,borrador, , ,buffer,”engagement: 3-5%”,si,”Revisar: no incluir datos personales en prompt”
    2026-09-03,blog,articulo,seo,”Resumen de 600 palabras sobre ‘productos sostenibles para cocina’ con H2 y meta description.”,openai/gpt-4o,borrador, , ,wordpress,”visitas: 50″ ,parcial,”Requiere comprobación de fuentes”

    Note on the template: required fields are fecha, canal, tipocontenido, objetivo, briefprompt, iagenerator, estadoqa, copyfinal, programador and automatizable. Mark “comentarioslegales” when the prompt or content includes or derives from personal data: those cases may require a DPIA or anonymisation.

    Column definitions

    • fecha: planned publication date.
    • canal: Instagram, LinkedIn, blog, newsletter, TikTok, etc.
    • tipo_contenido: post, carousel, article, short video.
    • objetivo: awareness, traffic, leads, sale.
    • brief_prompt: base prompt for the AI generator.
    • ia_generator: service used (eg OpenAI or another LLM).
    • estado_qa: draft / in review / approved.
    • copy_final: final text ready to publish.
    • imagen_url: link to the asset hosted (internal/CDN).
    • programador: scheduler or CMS used (Buffer, Loomly, WordPress).
    • metricas_esperadas: initial KPI targets (indicative).
    • automatizable: yes / no / partial.
    • comentarios_legales: flag if there are personal data or legal risks.

    Sector adaptation

    • For B2B services reduce posting frequency and prioritise LinkedIn; for local e‑commerce prioritise Instagram and Google Business.

    Practical example (SME persona): local e‑commerce — illustrative scenario

    Context (hypothetical): a brick‑and‑mortar and online gourmet food shop in Valencia with two staff. Objective: increase website visits and local sales within 30 days.

    Week 1: fill the template with 30 ideas. Four example posts for week 1 (headlines + prompt; illustrative):

    • Post 1 (Instagram): “3 quick recipes with our artisanal oil” — prompt: “Write a 90‑character Instagram copy inviting readers to try a quick recipe using oil X, include CTA ‘see recipe’ and a friendly tone.” (Automatable: yes; Human review required)
    • Post 2 (Facebook): “Behind the shop: how we select suppliers” — prompt: “Generate a 200‑word storytelling piece about selecting local suppliers.” (Automatable: yes; Human review and legal check required for third‑party mentions)
    • Post 3 (Email): “48h offer: breakfast pack” — prompt: “Create subject + preheader + email body for a promotional conversion email.” (Automatable: partial; mandatory review for promotions)
    • Post 4 (Google Business): “Extended opening hours and promotion” — prompt: “Neutral text with opening hours and a call to visit the shop” (Automatable: yes; verify factual details)

    Review and scheduling: the owner reviews, adjusts tone and approves. Posts are scheduled through your chosen manager using automated flows.

    Intermediate CTA (soft)

    Try the included CSV template: copy the CSV block into Google Sheets and adapt the columns to your calendar. This quick step lets you evaluate the flow and spot areas where human review is necessary.

    End‑to‑end operational flow: from idea to automated publication

    Pipeline summary (5 steps):
    1) Ideation + topic clustering (AI assisted)
    2) Briefing and draft generation (prompt templates)
    3) Human review/editing and compliance checks
    4) Scheduling and publishing (scheduler/API)
    5) Monitoring and reporting

    For each step: inputs/outputs, owner and typical tools

    1) Ideation + topic clustering

    • Input: objectives and buyer persona.
    • Output: indicative list of 30 ideas and theme calendars.
    • Owner: human + AI (LLM for idea generation).
    • Tools: OpenAI, other LLMs and spreadsheets.

    2) Briefing and draft generation

    • Input: selected idea and prompt template.
    • Output: draft copy and a visual proposal.
    • Owner: AI for the draft; human to adapt.
    • Tools: OpenAI API integrated via Zapier/Make/n8n.

    3) Human review/editing and compliance checks

    • Input: AI draft.
    • Output: final copy, marked with estado_qa.
    • Owner: human reviewer (human‑in‑the‑loop is mandatory).
    • Tools: Slack/Asana for reviews, compliance checklist.

    4) Scheduling and publishing

    • Input: final copy and assets.
    • Output: scheduled or live post.
    • Owner: scheduler automation + final human check.
    • Tools: Buffer/Hootsuite/Loomly/Wordpress + Zapier/Make/n8n to orchestrate.

    5) Monitoring and reporting

    • Input: platform metrics.
    • Output: weekly report and prompt/time adjustments.
    • Owner: human + scripts/AI for analysis.
    • Tools: Google Analytics, dashboards, spreadsheets.

    Generic example automation (6‑step Zap/Make/n8n flow)

    1. Trigger: new row marked “send to generation” in Google Sheets.
    2. Action: call OpenAI to generate three copy variants.
    3. Action: save variants in Google Sheets and notify Slack channel #reviews.
    4. Human action: reviewer marks a variant as “approved” in Sheets.
    5. Action: when state = approved, send to Buffer API to schedule.
    6. Final action: record publication ID in Sheets and send daily summary by email.

    If you prefer we can deploy the architecture and prepare it for your accounts as a consultancy service (offer subject to commercial terms documented separately).

    Prompt templates and prompting best practice

    Reusable templates (examples):
    1) Idea generator (short): “Give me 10 post ideas for [sector] focused on [objective: awareness/sales/lead] with a [tone] tone.”
    2) Social copy (Instagram): “Write an Instagram copy of [X] characters about [topic], include CTA ‘see more’ and one relevant hashtag.”
    3) Meta description: “Generate a meta description up to 155 characters for the article titled: [TITLE].”
    4) Long article summary: “Summarise the attached text into 5 bullet points with the key ideas.”
    5) Designer brief: “Create a one‑paragraph brief for a 3‑slide carousel about [topic], include colour palette and one sentence per slide.”
    6) Tone variants: “Rewrite the text to sound more formal / more friendly / more technical.”

    Prompting best practice

    • Don’t include concrete personal data in prompts (eg names, emails). Use anonymised variables if context is needed.
    • Always specify the target audience and tone.
    • If factual accuracy matters, add “cite sources” and review outputs manually.
    • Limit output length if the platform charges by tokens.

    Prompts that need special attention

    • Legal, medical or financial advice: never publish automated content without expert review.
    • Prompts comparing companies/competitors: check for defamation and accuracy.

    Technical automation examples by platform

    Zapier (example flow)

    • Flow: Google Sheets (trigger new row) → OpenAI (generate copy) → Google Drive (save assets) → Slack (notify team) → Buffer (schedule).
    • Key setup steps: connect accounts (OAuth/API keys), map fields, add filters (eg only channel X), configure retries and fallbacks.
    • Risks: task limits per month and latency. Check limits and prices on the provider’s official website before operating.

    Make (Integromat) (example flow)

    • Flow: webhook input → OpenAI call → data transforms in Make (add metadata) → CMS API to create draft → email notification.
    • Key steps: manage OAuth authentications, handle rate limits, use error handling modules.

    n8n (example flow)

    • Flow: scheduled trigger → HTTP Request (OpenAI) → Function (clean & anonymise) → HTTP Request (Buffer API) → log to database (Google Sheets/Postgres).
    • Advantage: n8n supports self‑hosting (recommended if you process sensitive data). Requires technical deployment skills.

    Where to add screenshots/JSON

    In your internal documentation include example JSON API calls and a trigger diagram. Never publish keys or real data.

    Pre‑production checklist

    • Run 10 end‑to‑end tests in sandbox (indicative).
    • Verify error handling (timeouts, fallbacks).
    • Confirm posts render correctly in staging (formats, links).
    • Human review final samples (at least two) before enabling full flow.

    Technical requirements and limitations to verify

    Checklist

    • API rate limits and cost per token/call: confirm on the provider’s official site before designing flows.
    • Timeouts and SLAs of the provider: consult TOS/DPA.
    • Supported formats by your CMS/scheduler (lengths, meta fields).
    • Policies and DPA availability: request a DPA if processing personal data.
    • Backoffs and retries: implement an exponential strategy.
    • Enterprise environments: consider enterprise accounts with DPA and audit logs.

    Recommendations for sensitive data

    • Don’t send identifiable personal data in prompts.
    • If unavoidable, set agreements, encryption in transit and a DPA with the provider and assess a DPIA.

    Practical tool comparison (summary)

    • OpenAI: LLM reference for generation; review TOS/DPA on their site.
    • Zapier: no‑code automation platform; check task limits and DPA on their site.
    • Make (Integromat): visual automations; check DPA on their site.
    • n8n: self‑host option for greater data control.
    • Buffer, Loomly, Hootsuite, ContentStudio: schedulers with differing integrations and costs; consult documentation and DPA pages.

    Note: DPAs/TOS and prices change frequently — document the URL, version and date of each check.

    Risks and compliance

    Practical summary

    • Consult EUR‑Lex and the European Commission for consolidated texts on transparency and obligations related to AI‑generated content.
    • For data protection consult AEPD (https://www.aepd.es) and EDPB (https://edpb.europa.eu).
    • For grants and calls consult Red.es (https://www.red.es) and the BOE (https://www.boe.es) to verify official calls and terms; never assume any funding without the official call.

    Transparency obligation (practical)

    • Be transparent: when you publish AI‑generated or AI‑assisted content include a visible notice and an AI policy on your site explaining the general use.
    • If local rules require a particular format or text, consult the official regulation and adapt.

    Data protection: DPIA and basic technical measures

    • Consider a DPIA if the AI processing involves systematic handling of special categories of data or a high risk to rights and freedoms.
    • Basic technical measures: minimisation and anonymisation beforehand, self‑hosted environments for sensitive processing, logging of artefacts and request a DPA from providers.
    • Reference sources: AEPD and EDPB (consult their official pages).

    Contracts and TOS: what to verify in a DPA/TOS

    • Existence of a DPA and security measures (encryption, transport).
    • Responsibilities for data and retention periods.
    • Rights of use and ownership of outputs (check provider TOS).
    • Audit clauses and sub‑processors.

    Intellectual property and commercial use of outputs

    • For commercial use check the provider’s TOS/DPA and, in complex cases, consult legal advice.

    Suggested transparency notice (example)

    • Short notice (post footer): “Content assisted by artificial intelligence. More info: /politica-ia” — adapt to applicable rules and link to your policy.

    Operational and security control checklist (actionable summary)
    Before enabling automation:

    1. Review TOS and request a DPA from providers (document date and version).
    2. Confirm whether a DPIA is required (consult EDPB/AEPD or legal counsel).
    3. Run sandbox end‑to‑end tests.
    4. Configure credential rotation and secure storage.
    5. Implement logging of prompts and responses with a retention policy.
    6. Define a human‑in‑the‑loop approval workflow.
    7. Set rollback and incident notification procedures.

    After enabling:

    1. Sample human monitoring in the first month (suggested frequency).
    2. Review metrics and the rate of manual corrections.
    3. Update prompts and templates based on results.
    4. Log incidents and corrective actions.

    Costs, resources and grants (how to check them)

    • Cost ranges (indicative): freemium tools = low; pro/API with moderate use = medium; enterprise integration with DPA = high.
    • NOTE: specific prices vary by provider and consumption. Always consult the provider’s official pages for prices and conditions.
    • Grants and subsidies: don’t assume availability without checking the official call on Red.es or the BOE.

    Measurement, metrics and continuous optimisation

    Key metrics to track (indicative):

    • Engagement per post (likes, comments, shares).
    • CTR on shared links.
    • Conversions attributable (sales, leads).
    • Human approval rate.
    • Editing time per post (estimated hours saved).
    • AI error rate detected.

    Recommended cadences

    • Operational review: weekly during month one; then monthly.
    • Performance reporting: weekly for active campaigns.

    FAQ
    1) Do I have to state that content was generated or assisted by AI?

    • Yes. Practising transparency is good practice. Adapt the notice to your jurisdictional requirements and consult the regulation if necessary.

    2) When is a DPIA necessary for using AI in content creation?

    • Consider a DPIA if you process personal data systematically, sensitive profiles or large‑scale personalisation. Consult EDPB/AEPD or legal counsel.

    3) Can I use model outputs commercially?

    • It depends on the provider and their TOS/DPA; review the provider’s official documentation and seek legal advice in complex cases.

    4) What contractual checks should I request from an AI provider before integration?

    • Request a DPA, retention and sub‑processor clauses, security measures and ownership of outputs. Document the date and version of the TOS.

    5) How do I check for official grants to implement AI in my SME?

    • Check Red.es, the BOE and regional portals for official calls and their terms. Do not rely on press reports without the official call link.

    Conclusion and recommended next steps

    Summary: with a focused 30‑day plan you can design, test and deploy an AI‑assisted content calendar while keeping human controls and legal checks in place. Immediate priorities: 1) start a pilot on two channels (for example Instagram and the blog), 2) document and request DPAs from your chosen providers, 3) include a transparency notice adapted to applicable rules and 4) enable human‑in‑the‑loop for the first 30 posts.

    Final CTA

    Request a Free Assessment and we’ll help you prioritise what to automate first and how to mitigate technical and legal risks (no guaranteed outcomes; initial free evaluation subject to terms).

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

    Keep reading

  • 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

  • From idea to working agent: AI automation projects for SMEs

    Introduction

    If you have an idea to automate tasks with an AI agent, this article explains, step by step and with clearly labelled practical examples, how to move from that idea to an agent running in production. It covers project phases, deliverables, acceptance criteria, legal risks (AI Act, GDPR and AEPD), funding sources and indicative cost ranges. Reference date: 25/08/2026 — check current calls for funding and regulations before making decisions.

    What you will find

    • A roadmap with clear phases and deliverables.
    • Practical checklists for each phase (including a DPIA checklist).
    • Indicative times and cost ranges and the variables that affect them.
    • Legal summary PAST / PRESENT / FUTURE with links to primary sources.
    • An anonymised illustrative case and text templates (RFP, acceptance criteria).

    Note: where the Spanish text uses the term pyme, we refer to SME (small or medium-sized enterprise) — the guidance is aimed at businesses operating in Spain.

    Overview: what does a real-world AI automation project look like for an SME?

    A “real-world” project here means a pragmatic, time-boxed effort for an SME to obtain an agent or automation that delivers measurable value (less time spent on task X, fewer errors, faster customer responses). This is applied work, not large-scale research or R&D: examples include conversational assistants for basic support, RPA enhanced with AI for data extraction, or internal assistants that suggest actions to employees.

    Typical small/medium scope:

    • Conversational agent for FAQs and ticket handling with CRM integration.
    • Invoicing automation: OCR extraction plus reconciliation in the ERP.
    • Internal assistant for searches and template text generation.

    Measurable results: time saved per task, first-contact resolution rate, percentage of tasks automated. Exact accuracy targets and metrics depend on the use case and should be defined during the diagnostic phase.

    Common project roles:

    • Internal sponsor (owner of the use case inside the SME).
    • Vendor / consultancy (implementation, architecture and deployment).
    • Data providers / system administrators (ERP/CRM).
    • Legal / compliance advisor (DPIA, contracts).

    Practical experience: at Momentum Logic AI we always recommend starting with a processes-and-data audit (diagnostic phase) before estimating costs or choosing technologies; that audit reduces the risk of rework.

    Recommended roadmap: phases, deliverables and success criteria

    Below we break down the phases. For each phase you will find minimum deliverables and acceptance criteria.

    Phase 0 – Diagnostic and prioritisation of use cases

    What to assess:

    • Business impact (hours/month saved, hourly cost, error-rate improvement).
    • Available data: volume, quality, access (APIs, CSV exports, databases).
    • Technical feasibility: legacy-system dependencies, public or private APIs.
    • Regulatory risks: whether personal data or automated decision-making are involved.

    Minimum deliverables:

    • Prioritised list of use cases with clear success metrics (KPIs).
    • Effort estimate (person-hours) and technical dependencies.
    • Recommendation on type of solution (SaaS, low-code, bespoke development).

    Mini-checklist (questions to validate a use case):

    1. Does it deliver measurable time savings or quality improvements?
    2. Is there a data source accessible today?
    3. Do the data include personal information?
    4. Is integration with ERP/CRM required?
    5. What is the expected daily usage volume?
    6. Is there staff willing to adopt the change?
    7. How much can the SME invest initially?
    8. What legal/regulatory risk exists?
    9. Which metrics will be tested in a PoC?
    10. Are there acceptable manual or semi-automated alternatives already?

    Phase acceptance criterion: a prioritised list with KPIs and a cost/time estimate for a PoC.

    Phase 1 – PoC / limited pilot

    Objective: validate the business and technical hypotheses with a limited scope.

    • Indicative time: 4–8 weeks for a simple PoC; projects with complex integrations or sensitive data and significant data engineering work may take longer in practice. Sector guides describe typical PoC durations.
    • Factors that extend timelines: data quality, IT dependencies, anonymisation requirements, legal clearances for testing.

    Deliverables:

    • Limited functional demo (minimal interface or basic integration).
    • Report with KPI results (accuracy rate, average time, critical failures).
    • Decision document: move to production, iterate or cancel.

    Data requirements for the PoC: test agreements, anonymisation/masking if real data are used. For personal data, consider a preliminary DPIA where appropriate.

    Acceptance criteria to advance: KPIs met as defined in Phase 0 and absence of insurmountable legal risks.

    If you’d like us to set this up with you and validate the technical feasibility in a practical workshop, at Momentum Logic AI we include this as part of our audit and prioritisation phase.

    Phase 2 – Design and integration (pre-production)

    Key activities:

    • Technical architecture: decide SaaS vs self-hosted model, cloud vs on-prem vs hybrid.
    • Integration design with ERP/CRM, message queues and APIs.
    • Security and privacy policies: access controls, encryption, backups.
    • Contracts and agreements: SLA, data-processing agreements, ownership clauses.

    Deliverables:

    • Technical design document and integration diagram.
    • Service-level agreements (SLA) and migration plan.
    • Test plan (including pentest/TT if relevant) and contractual checklist.

    Minimum contractual checklist (items to negotiate):

    • Data processing roles (controller/processor).
    • Server location / international transfers.
    • Data and model ownership (who trains and who retains weights or prompts).
    • Exit / data portability mechanism.
    • SLA and response times.
    • Liability for errors and security incidents.

    Phase 3 – Production and deployment

    Requirements to move to production:

    • Final tests with real data and acceptance criteria met.
    • Rollback plan and user communications.
    • Initial monitoring procedures.

    Indicative deployment time: an extra 2–6 weeks to integrate systems and train users, depending on coupling level.

    Deliverables:

    • Operational runbook and incident playbooks.
    • Initial production acceptance metrics (defined KPIs).
    • Security certificates or validations if external tests were contracted.

    Phase 4 – Operation, monitoring and governance

    Critical points:

    • Monitor performance (latency, error rate) and business metrics.
    • Detect and manage model drift.
    • Maintain datasets and plan retraining cycles.
    • Regular reviews of privacy and security.

    Deliverables:

    • Dashboard with key metrics.
    • Review cadence (monthly/quarterly).
    • Maintenance plan and operational SLA.

    Governance and roles checklist:

    • Business owner (measures KPIs).
    • Technical lead (manages deployment and runbook).
    • Data / privacy lead (DPIA and records).
    • Vendor support (SLA and updates).

    Timelines and costs: practical guidance (with caveats)

    Indicative ranges (market):

    • Basic SaaS (licence only): subscription models range from low-cost options to enterprise solutions; costs vary significantly by functionality and provider.
    • Low-code implementation / basic integration: market examples start at several thousand euros and rise with integrations and customisation. Review market analyses and integrator pricing guides before fixing a figure.
    • Bespoke development: substantially higher cost, depending on engineering hours, integrations and security requirements.

    Variables affecting cost and time: data cleaning, number of integrations, security requirements, certifications, number of languages, token/usage volume if pay-as-you-go models are used.

    Illustrative example (indicative only):

    • SME in services with two support staff aiming to automate FAQ responses and ticket routing.
    • PoC: indicative duration 6 weeks; the costs shown here are illustrative and should be treated as internal reference only — any specific figure requires a formal provider quotation.
    • Production (deployment + training + six months operation): budget items can vary widely; this is an illustrative reference, not a binding market figure.

    Legal note: all numbers in this article are indicative and should be validated with formal quotes.

    Quick timeline table (phase vs weeks)

    • Phase 0 (Diagnostic): 1–2 weeks
    • Phase 1 (PoC): 4–8 weeks
    • Phase 2 (Design/Integration): 2–6 weeks
    • Phase 3 (Production): 2–6 weeks
    • Phase 4 (Operation): ongoing (monthly/quarterly reviews)

    Regulation and compliance (how it affects you)

    Table PAST / PRESENT / FUTURE

    Periodo Resumen y acciones prácticas
    PASADO (hasta la referencia) AI Act (Reg. (EU) 2024/1689) publicado; consulte el texto oficial en EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
    PRESENTE (a 25/08/2026) AI Act en vigor con desarrollos normativos; la Agencia Española de Protección de Datos (AEPD) publicó orientaciones sobre Inteligencia Artificial agéntica (nota de prensa del 18/02/2026): https://www.aepd.es/prensa-y-comunicacion/notas-de-prensa/la-agencia-publica-unas-orientaciones-sobre-inteligencia
    FUTURO La regulación complementaria conocida como “Ómnibus Digital” (Reg. (EU) 2026/1744) introduce modificaciones y ajustes en el cronograma y obligaciones; consulte el texto en EUR-Lex: https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng

    Practical actions for the SME (translation of obligations):

    • Data protection impact assessment (DPIA): consider it when the agent processes personal data at scale or makes automated decisions; follow AEPD guidance where applicable.
    • Transparency (Art.50 and related): inform users when they are interacting with an AI system as required by the AI Act; review the relevant articles in EUR-Lex.
    • Responsibilities: distinguish provider and deployer roles in contracts and specify compliance obligations in the agreement.

    Important: concrete obligations depend on the system classification (high risk, transparency obligations, etc.). To determine what applies to your case, consult the Regulation text in EUR-Lex and seek specialised legal advice.

    Funding sources and grants (what to check before applying)

    Possible sources:

    • Kit Digital (managed by Red.es) — its last call closed on 31/10/2025 and there is no new call open at the time of writing; information and updates at: https://www.red.es/es/iniciativas/proyectos/kit-digital
    • Regional lines and sectoral grants.
    • ICO loans or bank financing.
    • Private financing or technology partners.

    Important warning: at present the Kit Digital has no open call, so it cannot be applied for unless you already hold an aid awarded in a previous call. Always check Red.es for updates before budgeting on the assumption of this aid.

    Checklist to prepare an application (Kit Digital or other grant):

    • Technical document describing the solution and its value for the SME.
    • Detailed budget and investment plan.
    • Accredited partner / digital agent (if the call requires one).
    • Company administrative documents (CIF, financial statement).
    • Evidence of data use and privacy measures (if applicable).

    Practical risks and mitigations

    Risks and countermeasures:

    • Legal (GDPR, AI Act): perform a DPIA when appropriate; include contractual clauses that allocate responsibilities.
    • Technical (data quality, drift): quality tests, labelling pipelines and scheduled retraining; monitoring for drift.
    • Security: access control, encryption in transit and at rest, pentests on exposed interfaces.
    • Organisational (adoption): change management plan, training and follow-up with usage KPIs.

    Mini-template of critical contractual clauses (suggested wording):

    • Confidentiality: the vendor commits not to disclose data and limits access to necessary staff.
    • Data processing: specify role (processor/controller), purposes and technical measures.
    • Data location: indicate countries/zones and transfer conditions.
    • SLA and maintenance: response times, availability and update schedule.
    • Exit mechanism: data export and deletion at contract termination.

    How to choose a provider and what to request in the contract

    Provider selection checklist:

    • Sector experience and verifiable references.
    • Evidence of achieved cases and metrics.
    • Documented security and privacy policies.
    • Integration tests and documented APIs.
    • Clear support and SLA commitments.

    Minimum RFI/RFP questions (mini-RFP):

    1. Do you have experience in similar projects (verifiable references)?
    2. How do you manage personal data? Do you subcontract?
    3. Where are data and models hosted?
    4. What SLAs do you offer (availability, response time)?
    5. What is the estimated cost for a PoC and for 12 months of operation?
    6. How is exit handled (data export)?
    7. What security measures and pentests has the system passed?

    Focused case study (anonymised) — from pilot to production in 10 weeks

    Anonymised case (illustrative and indicative):

    • Context: distribution SME with three support agents and a proprietary ERP.
    • Scope: AI agent for shipment queries and order status (ERP integration).
    • Indicative timeline: diagnostic 1 week; PoC 5 weeks (CRM/ERP integration + internal demo); design/integration 2 weeks; deployment 2 weeks = approx. 10 weeks total.
    • Costs (illustrative): PoC EUR 6,000; deployment and six months operation EUR 12,000 — these numbers were presented as an illustrative example by a provider in a specific case and require provider documentation/authorisation before being published as a real case.

    Lessons learnt: define business KPIs from Phase 0, include anonymisation tests and a rollback plan, and contract data portability clauses.

    Note: this “anonymised case” is presented as an illustrative example and requires documentary verification before being considered a published real case.

    Templates and resources (included in the text)

    DPIA basic checklist for agents/automations (summary):

    • Description of processing and purposes.
    • Assessment of necessity and proportionality.
    • Assessment of risks to rights and freedoms.
    • Measures planned to mitigate risks.
    • Record of stakeholders and decisions taken.

    Acceptance criteria template (example):

    • Main KPI reached: task time reduction >= X% (defined in Phase 0).
    • Minimum accuracy rate: >= Y% on the validation dataset.
    • Response time: < Z seconds for 95% of queries.
    • Compliance with identified legal requirements (DPIA completed if applicable).

    Mini-RFP: see the 7 key questions above.

    Links to primary sources (review before publishing):

    • AI Act (Reg. (EU) 2024/1689): https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
    • Ómnibus Digital (Reg. (EU) 2026/1744): https://eur-lex.europa.eu/eli/reg/2026/1744/oj/eng
    • AEPD (guidance 18/02/2026): https://www.aepd.es/prensa-y-comunicacion/notas-de-prensa/la-agencia-publica-unas-orientaciones-sobre-inteligencia
    • Kit Digital (general information): https://kitdigital.red.es/
    • Kit Digital management platform (beneficiary area): https://portal.gestion.sedepkd.red.gob.es/portal/espacioPyme/

    Conclusion and recommended next steps

    AI automation projects are feasible for SMEs if they are properly scoped: define KPIs during the diagnostic, validate hypotheses with a concrete PoC, and ensure legal compliance (DPIA and transparency) before deployment. Before applying for public aid, check the status of calls at Red.es and the BOE.

    Request a Free Assessment and we will tell you where to start realistically (note: any commercial offer must be detailed in a formal written quotation).

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

    Keep reading

  • How to choose the best AI assistant for your SME

    The idea of adding an AI assistant to an SME is attractive: faster responses to customers, automation of repetitive tasks and extracting information from documents. But once you start, key questions appear: what type of assistant suits you best? how do you protect customer data? how much time and resources will implementation need? This article is a practical comparison aimed at self‑employed professionals (autónomos) and small businesses operating in Spain, with clear criteria and actionable steps to help you make an informed decision.

    We are not here to promote any single vendor; instead this offers a reproducible method. I include the observations we apply in the Proceso Momentum (audit, architecture, local or cloud deployment, integration and optimisation) so you understand not only what to choose, but why and how to take it into production without surprises.

    Why you may — or may not — need an AI assistant in your SME

    An AI assistant can cut time spent on repetitive tasks (answering FAQs, sorting email, extracting invoice data), improve customer experience and free your team for higher‑value work. However, not every SME benefits in the same way: if most interactions are complex and require continuous human judgement, an assistant can only help with parts of the workflow.

    Before deciding, run a quick audit: measure the volume of repetitive enquiries, how much time your team currently spends on administrative tasks, and how many documents (PDFs, invoices, contracts) you need to process each month. That initial audit is part of our first step in the Proceso Momentum and prevents over‑investing in solutions that do not fit.

    Types of AI assistants and what they are for (practical summary)

    1) Rule‑based chatbots

    Ideal for very structured FAQs. They work with predefined flows (if the user says X, respond Y). They are simple and cheap to maintain, but break when questions fall outside the script.

    2) Generative conversational models

    These reply in natural language and can handle a wide variety of queries. Useful for support, sales and content generation. They demand more control over accuracy and data privacy.

    3) Retrieval‑Augmented Generation (RAG) assistants

    Combine searching your own documents (knowledge base) with a generative model. Good when you need answers based on your documentation: manuals, contracts, product datasheets.

    4) Vertical, integrated assistants

    Solutions built for specific sectors (accountancy, healthcare, e‑commerce) that include integrations and sector rules. They can speed up time to value but restrict flexibility.

    Practical selection criteria: what really matters

    When comparing options, prioritise these criteria in roughly this order:

    • Privacy and legal compliance
    • Integration with your systems (POS, ERP, CRM, email)
    • Quality of responses and control of the AI
    • Total cost (implementation + operation)
    • Maintenance and capacity for optimisation
    • End‑user experience

    Below we explain each point with plain language and concrete actions.

    Privacy and legal compliance

    For an SME in Spain, handling personal data requires care: keep logs, control access and decide whether data can leave to third‑party cloud services. Practical recommendation: if you work with sensitive client data, consider a local deployment or a cloud environment governed by a data‑processing agreement that meets the legal requirements. Check with your adviser or the Spanish Data Protection Agency for specific obligations: https://www.aepd.es

    Integration with your systems

    A useful assistant does not live in isolation. Check whether it can connect to the tools you already use (email, CRM, document manager, POS). Ask about APIs, standard connectors and whether additional development is needed. In the Proceso Momentum we typically map required integrations during the audit and estimate development hours before choosing a platform.

    Quality of responses and control

    It is not enough that the AI replies; it must reply correctly. Consider:

    • Ability to feed your own knowledge base (documents, FAQs)
    • Tools to correct or pin responses (instructions that prioritise your documentation over general knowledge)
    • Fallback mechanisms: when it does not know, escalate to a human

    Total cost (TCO)

    Always ask about: initial integration cost, per‑user/consumption cost (tokens, minutes, API calls), and maintenance cost. Don’t focus only on the monthly subscription: many implementations require configuration and fine‑tuning that add consultancy hours.

    Maintenance and optimisation

    All AI needs supervision: review conversations, update the knowledge base and tweak prompts or rules. Evaluate who will perform that maintenance: your team, an external provider or a combination. At Momentum we recommend regular cycles (for example monthly or bi‑monthly sprints) for review and continuous improvement.

    End‑user experience

    Consider available channels: web chat, WhatsApp, voice, CRM integration. Pilot prototypes with real users before a full public rollout.

    Practical checklist to ask a vendor

    When you speak with a vendor or try a demo, take this checklist with you:

    • How does it handle user data and where is it stored?
    • Can I deploy the assistant on my infrastructure or in a cloud with a data‑processing contract?
    • Does it have RAG capabilities to use my documents? How are they indexed?
    • What telemetry data is stored and for how long?
    • How are users authenticated and what access roles exist?
    • What integration and maintenance costs do you estimate?
    • What is the scaling plan if usage grows?
    • Can I train or tweak the assistant’s behaviour with my own examples?

    Answering these questions will give you a more realistic view than comparing only attractive screens or public demos.

    Illustrative case (hypothetical example)

    Example: an accountancy practice with 3 staff receiving about 500 enquiries a month on filing deadlines and appointment requests.

    Objective: reduce time on repetitive enquiries and automate appointment handling.

    Proposed route and hypothetical timings:

    • Audit and process map: 1 week (meetings and review of internal FAQs)
    • Knowledge‑base preparation (contracts, procedures, FAQs): 2 weeks
    • Development of integrations (calendar + CRM): 2–3 weeks
    • Testing and adjustment with real users: 2 weeks
    • Initial deployment and monitoring: 1 week

    Expected outcome (hypothetical): with a well‑structured knowledge base and proper integration, the assistant can automatically resolve a significant share of repetitive enquiries and reduce the team’s operational load. The scale of savings depends on documentation quality, interaction volume and flow design: that is why we recommend measuring baseline metrics before deployment and comparing them periodically.

    In this example we follow the Proceso Momentum: start with an audit, design the architecture (local or cloud deployment?), integrate calendars and CRM, and set a three‑month optimisation plan to refine responses.

    Common myths and mistakes to avoid

    • “Any assistant works for everything”: false. Some are good for FAQs, others for document processing.
    • Starting without data: without measuring volume and query types it is easy to oversize the solution.
    • Ignoring maintenance: AI is not a ‘set and forget’ technology; it needs supervision and adjustments.

    Quick checklist before deciding

    • [ ] I have measured volume and types of enquiries.
    • [ ] I know which systems must be integrated (CRM, calendar, document manager).
    • [ ] I have checked where data is stored and legal compliance.
    • [ ] The vendor allows control over the knowledge base.
    • [ ] I have a maintenance plan (who and how often).
    • [ ] I have tested with real users and have baseline metrics for comparison.

    How we work at Momentum Logic AI (process summary)

    Our usual approach with SMEs follows these practical steps:
    1) Operational audit: measure volume of enquiries, types and sources.
    2) Architecture: decide deployment (local or cloud), channel and integration scheme.
    3) Minimum viable deployment: prototype in 2–6 weeks depending on required integrations.
    4) Integration and security: connectors to CRM, calendar and document manager; access controls.
    5) Continuous optimisation: review conversations, prompt adjustments and knowledge‑base updates.

    If you need a legal check on data processing, you can start by consulting the Spanish Data Protection Agency: https://www.aepd.es

    Conclusion

    Choosing the best AI assistant for your SME is not about following a trend but about solving a specific problem with a solution you can integrate and maintain. Prioritise privacy, integration capability and a clear maintenance plan. Start with a simple audit and an MVP that lets you iterate.

    If you would like, we can help with a Free Assessment to determine which type of assistant best suits your business and estimate realistic timescales and scope with no obligation.

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

    Keep reading

  • Automation vs hiring staff: when each option pays off

    The choice between automating processes or hiring more staff is one of the most common — and costly — decisions for founders and small businesses. There is no single right answer: it depends on the type of work, volume, budget and growth objectives. This article provides a practical framework to decide without jargon, with concrete steps, realistic risks and a numeric example you can adapt to your own business.

    At Momentum Logic AI we usually reach the decision after an audit: map tasks, measure times and costs, and design an architecture that can host both people and tools. That Momentum Process — audit, architecture, local deployment, integration and optimisation — appears throughout because the decision is rarely “all or nothing”: it is common to combine automation with additional headcount.

    Why gut-feel alone is not enough

    Hiring and automating both bring clear benefits, but also hidden costs. Hiring typically resolves peaks and delivers human flexibility; automation reduces repetitive errors and scales without increasing headcount. Without measurement you risk paying salaries that don’t match real peaks or buying tools that don’t integrate with your existing systems.

    Before anything else, take three simple measurements: average time per task, direct cost (salary/hour or tool cost) and weekly/monthly frequency. With those three figures you can apply the criteria we set out below.

    Key criteria: when automation pays off

    • Repetitiveness and clear rules: tasks performed the same way many times (order processing, invoice reconciliation, automated reminders). If you can define the rule in a simple diagram, it is usually automatable.
    • Volume and predictability: the higher and more stable the volume, the better the ROI. If your volume rises, for example, from 50 to 200 operations/week of the same task, automation typically becomes worthwhile.
    • Low marginal cost per operation after automation: when the marginal cost per operation falls significantly (for example, from EUR 5 manually to EUR 0.5 automated) and you recover the investment within months.
    • Need for 24/7 availability or immediate response (chatbots, automated emails, real-time stock management).
    • Error reduction: repeated enquiries due to administrative mistakes, returns because of data errors, etc.

    Risks to consider before automating:

    • Maintenance and updates: a poorly designed automation can require hours of tuning each time a supplier changes a template.
    • Data privacy: if you process personal data, review your obligations with the Agencia Española de Protección de Datos (AEPD).
    • Initial cost and vendor dependency: evaluate whether the provider allows you to export your data and operate locally if needed.

    Key criteria: when hiring more staff pays off

    • Work requiring high human interaction and judgement: consultative sales, resolving complex complaints or creative work where empathy matters.
    • High volatility and non-standardisable tasks: if the workload is unpredictable and each case differs, a human can be more efficient than a rigid solution.
    • Immediate physical handling required (for example, receiving goods where there is variety of products and manual packing).
    • Legal or certification requirements that demand staff with specific professional credentials.

    Risks of hiring without automating:

    • Higher fixed costs (salaries, social security contributions, onboarding time). For official figures on average labour cost per worker and its evolution, consult the Instituto Nacional de Estadística (INE): https://www.ine.es. To calculate social security contributions and fees that apply in your specific case, consult the Social Security site: https://www.seg-social.es (obligations and percentages vary by contract type, sector and specific circumstances).
    • Duplication of tasks: several people doing work that could be centralised.

    Hybrid strategy: the most common and practical option

    Most of our projects follow a mixed route: we automate 60–80% of repetitive tasks and leave the remainder to people who handle exceptions. Typical examples:

    • An online practice manager that automates bank reconciliation and recurring invoicing, while a person handles client relations and atypical cases.
    • An e-commerce business that automates labelling, stock alerts and part of logistics, but keeps staff for packing, telephone support and complaints.

    At Momentum Logic AI we follow the Momentum Process: audit to identify what to automate, design the architecture (microservices, flows or no-code tools as needed), deploy locally if the client requires it, integrate with existing systems and optimise iteratively.

    If you would like a hand mapping which tasks are best automated and which should stay human, we can provide brief, practical advice at this stage — no obligation.

    How to calculate ROI: a practical step-by-step formula

    1) Measure (for the period you choose, e.g. monthly):

    • Total current time spent on the task (hours/month).
    • Effective hourly cost (if hiring: salary + social costs + extras; if automating: platform cost divided by users/month). If you do not know the exact social cost figure, consult the Social Security site to get the applicable rates and contribution bases: https://www.seg-social.es.
      2) Estimate the saving after automation (% of time eliminated or reduced).
      3) Calculate monthly saving = time saved (h) × hourly cost.
      4) Calculate solution cost: initial investment + monthly maintenance cost.
      5) Simple ROI (months to recover) = total initial cost / monthly saving.

    This method tells you how many months it takes to recover the investment and whether it makes sense compared with hiring.

    Illustrative example (hypothetical)

    A carpentry workshop with an online store receives 150 orders per month. The current manual process: 12 minutes of handling per order (confirmation, invoice, label and customer notice) → 150 × 12 = 1,800 minutes = 30 hours/month.

    Costs:

    • Effective hourly cost of the employee doing the handling: EUR 14/hour (hypothetical).
    • Monthly cost for that task = 30 h × EUR 14/h = EUR 420/month.

    Alternative A — hire a part-time person (20 h/week ≈ 86 h/month): simplified hypothesis, without exact social charges.
    Alternative B — automate: a platform that reduces handling to 2 minutes/order and costs EUR 250/month, with an initial setup cost of EUR 500.

    Savings with automation: (12 − 2) min × 150 orders = 1,500 min = 25 h → monthly saving = 25 h × EUR 14/h = EUR 350/month.

    Months to recover = EUR 500 / EUR 350 ≈ 1.4 months (not counting later optimisations). In this illustrative example, automation pays off if your business maintains that volume. If orders were 20/month the equation changes.

    Note: this example does not replace your real numbers. Substitute your own figures and apply the formula above.

    Practical checklist to decide (use before calling a provider or posting a job advert)

    • [ ] I have measured time per task and frequency (hours/week).
    • [ ] I have calculated the real hourly cost (including social charges if hiring) or the monthly cost of the tool.
    • [ ] I have estimated a realistic saving after automation (conservative: 40–80% depending on the task).
    • [ ] I have evaluated risks: maintenance, privacy and vendor dependency.
    • [ ] I have trialled a small pilot (1–3 months) before rolling out across the company.
    • [ ] I have defined success indicators (reduce time X%, lower errors Y%, improve customer NPS).

    Cases where we prefer to hire first

    • You are growing but need immediate physical presence (for example, opening a new point of sale).
    • Customer service requires human treatment and complex resolution.
    • You want to build culture or expand the team with skills you can later support with automation.

    Practical implementation tips

    • Prioritise a pilot on a high-volume, low-risk task.
    • Document current processes before automating (a clear flow reduces development hours).
    • Demand data export and modular designs to avoid vendor lock-in.
    • Always keep one person responsible for exceptions and continuous improvement.

    Resources and legality

    For statistics on companies and employment in Spain consult the Instituto Nacional de Estadística: https://www.ine.es. For questions about processing personal data review the Agencia Española de Protección de Datos: https://www.aepd.es. For information and tools to calculate social security contributions and fees, consult: https://www.seg-social.es.

    Conclusion and next step

    There is no single rule: the decision depends on volume, repetitiveness and the real cost of supporting people versus tools. Generally, automate the repetitive and hire for what requires human judgement. The hybrid option is the most practical for most small businesses.

    If you wish, we offer a Free Assessment for your business: we measure tasks, project savings and propose a plan using the Momentum Process (audit, architecture, local deployment, integration and optimisation) — without obligation.

    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