← Back to Insights
Research3 min read

What can you actually use Sweden's digitalisation grant for?

By Mohammed AlsaadiLäs på svenska

If you already know you qualify, the harder question is what counts as an approved project. Two companies with identical circumstances can get different answers on the same kind of application, because they described the project differently. Here's how to avoid that.

The regions phrase it differently, but the pattern holds everywhere: the grant approves three kinds of work. Digitalising business processes. Building new services out of data you already have. Automating internal workflows. Everything else gets measured against whether it genuinely belongs in one of those three.

What gets approved

Data structure. Moving customer data from scattered systems into your own database. Building one knowledge source employees can actually search. Structuring a company's processes, decisions, and exceptions into a reusable form, including as the basis for an AI agent.

Automation. Invoice handling, case management, reporting that's currently done by hand. The requirement is that it's a process you already run, not something new built for a client from scratch.

Digitalising a paper process. New-hire onboarding is a common example: the introduction plans, checklists, and handbooks that currently live in binders or get scattered across email, moved into one digital, structured form.

Checklist: which project types get approved and which get rejected

What gets rejected

Marketing and sales. Region Stockholm excludes it outright. A project described as campaign work, sales development, or content production gets rejected regardless of the technical content underneath.

Licences. Buying software rarely counts as eligible on its own. The work of setting it up and adapting it can be, the licence cost isn't.

Standalone training. A course package that stands on its own gets rejected in most regions. Skåne is more permissive: competence transfer that sits inside a larger project can qualify, a standalone course package can't.

Normal operations. Administration, project management, and ongoing business activity are explicitly excluded everywhere.

Same project, two descriptions

Take a concrete example. A company wants to build an AI-driven knowledge source, automate seven internal workflows, and train the team on how to use the system.

Described as "AI-powered sales engine with a trained sales team," a caseworker reads that as sales and training, both excluded in Stockholm.

Described as "digitalising the company's knowledge structure, with seven automated process flows and competence transfer inside the project," it's the exact same build, described the way the regions actually ask for it.

Nothing about the technical work changed. What changed was the words used to describe it, and that's usually the only thing deciding whether the application goes through.

Before you write the application

Write down what the project actually builds, not what it gets used for afterward. An AI agent trained on your company's processes is one thing. That it later gets used in sales work is another, and that distinction is exactly what a caseworker looks for.

We build exactly the kind of project the grant approves.

Structured knowledge, automated workflows, nothing that reads as sales or training. Book a free call and we'll frame the project together.

Book a call

Request a demo.

Walk through your context gap with us.

Request a demo

Join the newsletter.

A weekly summary of new insights, plus what's new at Opmore. No spam, just insights.