Most of it is already built. The part that has to fit your reality is built with you.
We bring what we have built and tested with other groups, and shape it to yours, in your environment, with the people who do the work today. Nothing is built before we have seen their week.
[Industrial group, awaiting approval][Industrial group, awaiting approval][Municipalities, awaiting approval]Microsoft partnerA standard system, a build from scratch, and what we do: how well each fits the systems you already run, and how much of it was built and tested before you.
Three steps
-
Map the reality.
We interview the units, read their own files and describe their week before anything is built. Where the documents arrive, who types what over, which table someone copied last year, how many hours the quarter takes and where they go. The mapping also shows which units carry the result, so the first version starts where it matters.
-
Build in your environment.
Our engineers work inside your organisation, on your systems, alongside the programmes you already run. A first version stands in your environment within weeks: infrastructure as code in your Azure, roles from your directory, the model in your tenant. Documents keep arriving as they do today, and the specialist judges a flagged row with the document beside it.
-
Lift out what recurs.
What works in one unit, or one function, becomes something we bring to the next. The same register, the same checks and the same trail carried the climate figures first, then the training records and the cases. Each new requirement starts from what the last one built.
The first step on one assignment, from the question to the basis for the board's decision, is told under sustainability on Where we work.
What we bring, and what we shape with you.
Groups run different systems, have different histories and different teams, and have come different distances in what they want from the data. One builds in its ERP, another in a data warehouse, a third in the consolidation system, and most have companies outside all of them. A standard system needs the group to fit it. A build from scratch fits, but everything in it is new and tested for the first time on you.
We work in between, and bring what has been built and tested before. Each part is used whole, in part, or not at all, depending on what you already have. The less that has to fit, the closer it comes to a finished product. The Cards is both ends of that range.
What we bring
Working code for the parts every requirement needs: reading documents where they arrive, a register of definitions, checks before anyone signs, periods and approvals, a trail from the sum to the line. Solution designs that have been through a review. Curated data, such as factor tables and the map between versions of a standard. Instructions that let AI do the routine parts of the build the same way each time. And the experience of having done it with other groups, including what went wrong.
What we shape with you
What a row is in your case, what your register holds, and where the sum goes. Which system the data is read from and which one it lands in. Which units sit outside the main systems and how they report. Who approves what, and who may see the detail. How far you want to go now, and what can wait.
What stays as it is
Your systems, units, countries and ways of working. The documents keep arriving as they do today, the specialist judges where they already work, and the group sees its totals where it does today.
What changes, and for whom.
The unit
Sends what it already has. Where invoices and files can be fetched from mailboxes, portals or systems, the unit does nothing new. Where they cannot, it uploads the file it already keeps, in place of the spreadsheet it fills in today, signed in with the account it already has. A case is registered by the HR manager when it happens, and only the roles that handle it can open it.
The specialist
Judges only what is flagged: the row, the place in the document beside it, a choice. The decision is recorded with their name. The typing over, the copying and the checking by hand are what goes.
The controller
Approves the unit's figure with the evidence one click away, instead of chasing a file, checking it again by hand and typing it into the consolidation system. The figure arrives there already approved.
The group and the auditor
The group sees its totals where it does today: in the consolidation system, in reports, in Copilot. Approvers and auditors can read the rows behind every total where their role allows, without being able to change them. For cases, the group sees counts, not content.
IT
An application in your Azure, built as code on a private network, with sign-in and roles from your directory. Who runs it, where the data is and what stays yours are in the facts below.
AI reads. People approve. Over time the two sharpen each other.
A model reads the document, proposes the factor, the match or the category, and writes down why. A person judges the rows that are flagged, and the judgement is recorded with their name. Nothing becomes a figure in your report because a model said so.
Every judgement goes back into the next version: the thresholds, what counts as flagged, the words your organisation uses for its own purchases and sites. In the factor work with Peab, the cycle of sample, proposal, comparison and correction ran until two rounds agreed within a threshold set beforehand, and the model is Peab's own. The judgement is more thorough than hands could make it, with a reason on every row that holds up to the auditor.
This is how trust is built: the AI handles the heavy lifting, and the experts ensure the results are accurate.
Our own account of the factor work with Peab, published on iconsof.se.
Both sides in the same people
The work sits between the substance of a requirement and the IT that has to carry it. A requirement has to be read correctly and then expressed as data models, interfaces and system boundaries an IT organisation can act on. Where that translation is missing, work of this kind stalls between the two sides.
We have both sides in the same small group, and it shows in one place in particular. In MASSIV+, the Swedish standard for sharing climate data across industrial value chains, we wrote the allocation rule in the standard and we built the dataspace connector that carries the data between companies. The people are on the people page.
AI in how we build
A small senior team is enough because a large share of the code is written with AI, under the engineer who owns it, with tests, infrastructure as code and a security review run on every release with the same tooling we offer to clients. That is why a first version stands in your environment within weeks and why there is no junior layer on your delivery.
One example. When the European Commission adopted the revised ESRS in July 2026, we mapped the datapoints of the 2023 standard onto the 2026 structure, disclosure by disclosure, in one day: a model drafted the mapping, a person curated every relation, and an external reviewer went through it the same day. The curated table is what now moves a report from one version of the standard to the next, with the uncertain relations queued for a person instead of filled in silently.
What a buyer asks before signing.
- Invoices and files in mailboxes and supplier portals
- The file a unit already keeps
- The ledger or the purchase system
- A case, registered when it happens
- Intake: every original kept, with a checksum
- Register, checks, approvals and the trail
- Database, files and keys on private endpoints
- Sign-in and roles from your directory
- Where a model reads a document, it runs here, inside the EU
- Specialists and approvers in the application
- Totals to your consolidation system or Microsoft Sustainability Manager
- Reports and the auditor's read access
- Copilot and your agents through MCP, where you allow it
Where the data arises, what runs in your Azure, and where it is used.
Where the data and the model are
In your Azure subscription and your region; the application we built for one group runs in Sweden Central. It is infrastructure as code on a private network, with locks on what must not be deleted. The database, the files and the keys sit on private endpoints, and the pipeline deploys with a federated identity rather than a stored credential. Where a model reads a document, it runs in your Azure, inside the EU, and nothing is used to train it. The Cards, as a service, runs in Microsoft Azure in Sweden.
Who can see what
For cases, the table of who sees what is on Where we work. Sign-in from your directory, with roles as app roles in Entra scoped per reporting unit, so who may submit, approve and read is decided where you already decide it. The role decides who sees the row and who sees only the sum. Every approval records what the approver opened. Retention per kind of record is written down; in the application we built for one group, access is removed within 30 days after it is no longer needed.
Copilot and your agents
The data is reachable from Copilot and your own agents through MCP, with scopes per token that you set and an audit log of every call, or not at all. A value an agent writes is saved marked for review until a person accepts it.
Who runs it afterwards
We do, under contract, with most of the effort on the days around the reporting windows. Or your own team does, or another supplier. The code lives in your DevOps, and the threat model, the network topology, the incident response plan, the data map and the processor inventory are documents in the repository, written to be reviewed against the environment.
What is yours, and if we are gone
Your data, your configuration and what is built for you are yours, and they are in your environment, so nothing has to be handed over from us. What stays with us is what we bring: the parts we have built before and the tools we review with. You get the full right to use it, change it and let someone else maintain it. That right goes into the contract. [Contract text in preparation]
Certification and sub-processors
[Certification status to confirm] For a solution in your environment, the services that process the data, Entra, App Service, the database, storage and email, are under your Microsoft agreement. When we run it under contract, or use AI tools on your code during the build, we are a processor too, under a data processing agreement. [DPA template in preparation] For The Cards, the list with region per supplier [In preparation].
Cost
A pre-study at a fixed price, described on Start. Building is time and material against a plan in releases. Running is an agreement sized to the reporting windows, and the Azure consumption is on your own subscription. [Price levels to confirm]
Start with a pre-study.
The first of the three steps can be bought on its own, as a pre-study at a fixed price.
Start with a pre-study