Finance needs a better foundation for decision-making

Solitwork can support a range of processes within and around the finance function.

The specific solution is assembled around the company’s requirements and can be expanded over time.

• management reporting
• financial reporting
• budgeting and forecasting
• financial consolidation
• data validation and reconciliation
• performance management
• ESG reporting
• carbon accounting
• collection of financial and non-financial data.

Yes. Solitwork can be used to structure and automate the company’s management reporting.

The solution can combine data from multiple sources and present it in reports, dashboards and analyses tailored to different audiences and management levels.

The goal is to create more consistent reporting and reduce the time finance spends collecting and processing data, such as revenue and earnings, costs, cash flow, working capital, variance against budget and forecast, operational KPIs, ESG and sustainability data, and many more.

Yes. Solitwork can support budgeting and forecasting processes across the organisation. The setup can be adapted to the company’s planning model and organisational structure.

• collecting input from the organisation
• managing budget versions
• workflows and approvals
• calculations and allocation keys
• consolidating budgets
• comparing actuals, budget and forecast
• scenario analysis.

Yes. Solitwork can support the consolidation of financial data from multiple legal entities and systems. The specific functionality and setup depend on the group structure and reporting requirements.

Our capabilities include loading data from subsidiaries, mapping charts of accounts, currency translation, intercompany eliminations, ownership structures, consolidation adjustments, documentation and reconciliation and group reporting.

Yes. One of the advantages of Solitwork is the ability to combine financial and non-financial data in a common reporting and data foundation.

This makes it possible to analyse relationships between financial performance, operations and sustainability.

That depends on the company’s current system landscape and requirements.

In some cases, Solitwork can replace existing manual or fragmented solutions. In other cases, it will work alongside the company’s ERP systems, data platform, BI tools and other applications.

The objective is not necessarily to replace every existing system, but to create a more coherent setup for data, processes and reporting.

Yes. The solution can be established in phases and expanded as the company’s requirements develop.

A company might start with management reporting or ESG data collection and later add budgeting, forecasting, consolidation or carbon accounting.

A phased approach can reduce project complexity and make it possible to realise value continuously.

Solitwork can integrate with different ERP systems, databases, data platforms, spreadsheets and other business systems. The integration method depends on the source system, data availability and the company’s IT architecture.

• ERP systems
• CRM systems
• HR and payroll systems
• production systems
• energy management systems
• procurement and supplier systems
• data warehouses
• Excel and CSV files
• external data sources.

Solitwork can be used in system landscapes where data comes from Microsoft Dynamics, SAP, Oracle and other ERP platforms. Integration can be established in different ways, for example through databases, APIs, file extracts, data platforms or existing integration layers.

The most appropriate method is assessed as part of the solution design.

No. Solitwork can be used to combine and structure data from multiple systems and organisational units. The company does not need to have established a single data foundation in advance.

In many projects, an important part of the work is defining how data from different sources should be connected, validated and used in reporting.

Yes. Solitwork can support manual data entry and loading data from Excel or CSV files.

This can be relevant when data is not available in a central system, which is often the case for ESG, supplier and activity data.

The general objective should be to automate data collection where possible and commercially relevant. Manual processes can still be included with validation, workflow and documentation.

Data quality can be supported through validation rules, reconciliations, controls, approval processes and clear data ownership.

Technology can support data quality, but quality also depends on clear processes, definitions and ownership within the organisation

Yes. The solution can support traceability from reported results back to the underlying data, calculations and data sources.

This makes reporting easier to explain, control and document. The level of traceability depends on the specific setup and the quality of the available source data.

The update frequency depends on the company’s requirements and the individual data sources. Some data can be updated automatically and frequently, while other data is collected monthly, quarterly or annually.

The frequency is defined based on the reporting process, data availability and the business value of more frequent updates.

Yes. Solitwork can support the mapping and harmonisation of data from entities with different charts of accounts, systems and local structures. Data can be translated into a common group model while retaining the local data and definitions.

This makes consistent group reporting possible without necessarily standardising every local system from the outset.

Not necessarily.

Solitwork can often be established on top of the company’s existing system landscape and combine data from the systems already in use.

In some projects, however, data models, integration processes or master data may need to be adjusted to achieve the required data quality and automation.

A typical implementation begins with clarification of the company’s requirements, processes, data sources and desired outcomes.

The specific project model is adapted to the size and complexity of the assignment:

1. Define scope and success criteria
2. Map processes and data sources
3. Design the data model and solution
4. Establish integrations
5. Configure and develop the solution
6. Test and validate
7. Train users and hand over the solution
8. Go live and provide ongoing support.

The implementation timeline depends on the scope of the solution, the number of data sources, the company’s organisational complexity and the quality of the existing data.

A limited solution can be implemented faster than a larger group solution involving multiple processes, entities and systems. At the start of the project, a plan is prepared with specific deliverables, roles, dependencies and milestones.

This depends on the content of the project, but participation from finance and relevant data or system owners will typically be required.

It is important to appoint an internal project owner and people with the authority to make decisions about processes, definitions and the data foundation.

Yes. It is often possible to begin with a limited pilot project or an initial phase. A pilot can be used to validate the solution design, build internal learning and document value before scaling the solution:

• one reporting process
• one business area
• a selection of legal entities
• a limited number of data sources
• a specific ESG or carbon accounting area.

The implementation is typically carried out as a collaboration between Solitwork and the customer’s project organisation.

Solitwork contributes software expertise, solution design, data understanding and experience with finance and reporting processes.

The customer contributes knowledge of its own processes, systems, data, organisation and reporting requirements. Clear accountability for decisions, data and deliverables is essential to an efficient project.

The solution is tested continuously during implementation and before go-live. The customer plays a central role in validating that the solution supports the agreed processes and reporting requirements by:

• checking data loads
• reconciliation to source systems
• validation of calculations
• testing reports and dashboards
• testing user access
• testing workflows
• user acceptance testing.

Training is adapted to the different user roles and the solution being implemented. It can be supplemented with documentation, guides and ongoing support for e.g. administrators, super users, reporting owners, or management users.

That depends on the solution design and the agreed division of responsibilities. Some elements can typically be administered by the customer’s own super users, while major changes to data models, integrations or calculation logic may require Solitwork involvement.

The desired level of self-service and internal knowledge transfer should be agreed as part of the project.

Solitwork can support the collection, structuring, validation, calculation and reporting of ESG data. The specific solution is adapted to the company’s reporting requirements, maturity and data foundation.

It may include:

• collecting data from systems and the organisation
• structuring ESG data points
• documenting definitions and methodologies
• validation and approval
• calculating ESG metrics
• reporting across legal entities
• tracking targets and performance
• establishing an audit trail.

Solitwork can be used as a data and reporting platform in work relating to CSRD and ESRS.

The solution can support the underlying processes, including data collection, calculations, documentation, controls and reporting.

The company remains responsible for determining its reporting scope, interpreting requirements and ensuring final compliance. Legal and assurance-related assessments should be carried out by the company’s relevant advisers and auditors.

Yes. The solution can be used to collect ESG data from different legal entities, locations, functions and systems.

Data can come from automated integrations, file uploads or manual entries. Workflows and validation rules can be used to manage responsibilities, deadlines, controls and approvals across the organisation.

Yes. The solution can support documentation of data sources, definitions, calculation methodologies, assumptions and changes.

This is particularly important in ESG reporting, where data often comes from many sources and may be based on measured values, estimates and calculations. Structured documentation makes reporting easier to control, explain and assure.

Solitwork can support traceability and documentation by recording data sources, changes, calculations, controls and approvals.

This can help make the reporting process more transparent and assurance-ready.

The final assessment of whether the documentation is sufficient depends on the company’s requirements and the specific assurance or audit process.

No. ESG data and documentation can also be relevant to companies that are not directly subject to mandatory reporting.

A structured ESG data platform can therefore create value beyond statutory reporting:

• customers
• banks and investors
• parent companies
• tenders and contracts
• supply chains
• employees
• internal sustainability targets.

Yes. The solution can be used to track developments in ESG metrics and compare results with targets, budgets or prior periods. This makes it possible to use ESG data actively in performance management rather than only in annual reporting:

• greenhouse gas emissions
• energy consumption
• renewable energy
• occupational health and safety
• diversity
• waste
• water consumption
• supplier performance.

Yes. ESG data such as emissions per unit of revenue, ESG performance across legal entities, costs associated with sustainability initiatives, development in financial and non-financial KPI, etc. can be connected with financial and operational data.

This can strengthen both the decision-making foundation and the internal integration of ESG into business management.

Carbon accounting is a structured method for calculating a company’s greenhouse gas emissions.

The inventory typically covers emissions from the company’s own activities, purchased energy and the value chain. The purpose is to create a documented foundation for reporting, target-setting and reduction initiatives.

Solitwork can support the calculation and reporting of emissions across Scope 1, Scope 2 and relevant Scope 3 categories.

The solution can combine activity data, emission factors and calculation rules in a structured model.

The categories that should be included depend on the company’s activities, value chain, materiality and reporting requirements.

Scope 1 covers direct emissions from sources owned or controlled by the company, such as fuel consumption in company vehicles or facilities.

Scope 2 covers indirect emissions from purchased energy, such as electricity, heating or cooling.

Scope 3 covers other indirect emissions in the company’s value chain. These may include purchased goods and services, transport, business travel, employee commuting, waste, use of sold products and investments.

Emissions are typically calculated by multiplying activity data by a relevant emission factor. The emission factor converts the activity into carbon dioxide equivalents, or CO2e.

The quality of the calculation depends on the quality of the activity data, the relevance of the emission factor and the assumptions applied, e.g.:

• litres of fuel
• kilowatt-hours of electricity
• kilometres travelled
• kilograms of material purchased
• financial procurement value
• number of hotel nights or flights.

The selection of emission factors depends on the data type, geography, reporting methodology and the company’s requirements.

Emission factors may come from public databases, industry sources, energy suppliers, supplier-specific information or other recognised sources. They should be reviewed and updated regularly.

Yes. The solution can be configured for different calculation methodologies.

• Activity-based calculations use physical activities such as energy, weight, distance or volume.
• Spend-based calculations use the company’s financial procurement data and emission factors per unit of currency.

Activity-based data is often more precise, but spend-based methods can be relevant where more detailed data is not available.

Yes. The carbon accounting solution can develop as the company gains access to more precise data. A company might start with spend-based calculations and later move to activity-based or supplier-specific data.

Method changes should be documented so that performance over time can still be explained and compared.

Yes. The solution can apply different emission factors depending on factors such as country, energy source, transport mode or activity type.

This is particularly relevant for companies with international operations, where the emissions intensity of electricity generation, for example, can vary significantly between countries.

Yes. Carbon accounting data can be used to establish a baseline, identify material emission sources and track progress against the company’s climate targets.

Software can provide the data foundation, but prioritising and implementing reduction initiatives requires business decisions, such as:

• tracking emissions over time
• comparing performance with targets
• analysing reduction initiatives
• reporting by legal entity and activity
• scenarios and projections.

Yes. Emissions data such as emissions per unit of revenue, emissions intensity across legal entities, the cost of reduction initiatives, development in both financial and climate-related KPIs, etc. can be connected with financial and operational data.

This relationship can make carbon accounting more relevant to finance and management.

Access to the solution can be adapted to different user roles and areas of responsibility. This means that users only receive access to the data and functions relevant to their role.

The specific access structure is agreed as part of the solution design:

• legal entity
• department
• geographic area
• reporting area
• user role
• administrative permissions.

Yes. The solution can be configured with role-based access.

Role-based access helps protect data and establish a clear division of responsibilities between

• administrators
• super users
• data owners
• approvers
• reporting users
• management users.

Data security is managed through a combination of technical, organisational and process-related measures.

The specific security setup depends on the solution architecture, hosting, integrations and customer requirements.

Relevant topics such as access management, data transfer, operations, backup, data processing and responsibilities are reviewed as part of the customer dialogue.

Solitwork’s processing of personal data must be performed in accordance with applicable data protection rules and the agreements entered into with the customer.

During implementation, the parties clarify which personal data is processed, why it is processed and how it is protected. Where relevant, a data processing agreement is entered into between the parties.

Depending on the specific setup, the solution can support logging, version control and traceability. This is particularly relevant in reporting processes with internal control and audit requirements.

• who loaded or changed data
• when a change was made
• which approvals were completed
• which calculations were applied
• which version of the data is included in a report.

Yes. The solution can be configured with validations, reconciliations, workflows and approvals that support the company’s internal control environment.

Technology can make controls more systematic and documented, but the company remains responsible for defining the relevant controls and assigning accountability within the organisation.

The location and processing of data depend on the selected technical architecture and the specific customer agreements.

Matters such as hosting location, subprocessors, backup and data transfers should be clarified and documented as part of the technical and contractual process.

The price depends on the scope and complexity of the solution. Based on an initial requirements assessment, Solitwork prepares a specific proposal:

• selected functionality
• number of users
• number of legal entities or units
• number of data sources and integrations
• reporting requirements
• implementation scope
• requirements for advisory services and support.

The licence model is adapted to the solution and use case required by the customer. It may depend on factors such as functionality, users, organisation size and solution scope.

The specific licence terms are described in the proposal and subsequent agreement.

Implementation and the recurring software licence are typically handled as separate elements.

The implementation covers establishing the solution, which may include design, integrations, configuration, testing and training.

The licence covers ongoing use of the software and the services agreed as part of the subscription. The specific division is set out in the proposal.

Yes. It is often possible to begin with a limited scope and expand the solution over time. This can reduce the initial investment and make it easier to document value before scaling.

However, the first phase should be designed with a long-term perspective so that it can be expanded without unnecessary complexity.

Recurring costs will typically consist of the software licence and any agreed service, support or advisory services.

There may also be internal costs associated with administration, data maintenance and the development of the company’s processes.

The specific costs depend on the scope of the solution and the selected collaboration model.

Support is adapted to the specific solution and agreement. The support model, contact channels and service levels are described in the specific agreement:

• help with errors and operational issues
• questions about use of the solution
• assistance for super users
• changes to reports and models
• advice on processes and data
• further development of the solution.

After go-live, the solution moves into operations and ongoing use. It is beneficial to establish a clear governance model for ownership, prioritisation and further development:

• support
• follow-up
• bug fixes
• continuous improvements
• new reports
• new data sources
• expansion to additional business areas
• adaptation to new requirements.

Solitwork continuously develops and maintains the software platform.

Updates may include improvements, bug fixes, technical updates and new functionality. How updates are implemented in the individual customer solution depends on the solution architecture and the specific agreement.

Yes. The solution can be developed as the company, organisation or reporting requirements change. Major changes should be assessed in relation to the existing data model and the long-term solution architecture.

The changes may include:

• new legal entities
• new data sources
• new KPIs
• changed reporting structures
• new ESG requirements
• new budget or forecast models
• changes to the group structure.

The customer owns its own data.

Rights, processing, storage and access are governed by the agreements entered into between the customer and Solitwork.

The parties should also clarify how data can be delivered or transferred if the collaboration changes.

Data and reports can generally be made available in relevant formats depending on the solution and use case. This may be for further analysis, reporting, documentation or integration with other systems.

The specific export options depend on the setup.

Yes. Solitwork combines software with advisory services relating to data, processes, reporting and solution design.

The scope depends on the customer’s requirements and internal capabilities:

• design of reporting processes
• development of data models
• structuring ESG data
• carbon accounting
• finance transformation
• governance and responsibilities
• automation of manual processes.

Yes. Solitwork can collaborate with the company’s auditors, consultants and other advisers. Roles should be clearly defined so that accountability is clear.

Solitwork primarily focuses on operationalising data, processes and reporting in a technical and business solution:

• interpretation of legislation
• methodology choices
• data foundation
• technical implementation
• controls
• audit or assurance.

A typical first step is an initial discussion about the company’s current processes, challenges and objectives.

Based on the discussion, Solitwork can help define the relevant scope, data sources, stakeholders, expected business value and a possible project and implementation model.

A specific solution proposal can then be prepared.