Configuration

Sweden

A configuration guide to being compliant in Sweden

This document provides a step-by-step configuration guide for a compliant setup in Sweden.

Compliance in Sweden at a glance

Which flows are affected?

✅ B2C

✅ Ecom

✅ B2B

Which flows are not covered?

✅ Ship from Store

✅ Click & Collect

✅ Endless Aisle

Which type of fiscalization is required?

✅ Local rules and legislation

✅ Third party software integration required (Infrasec)

✅ EVA is directly integrated with the tax authority via Infrasec

❌ Special hardware required

Who needs certification?

✅ New Black

❌ Retailer

Introduction

In Sweden, businesses must report their sales transactions and invoices to the tax authorities. This document outlines the necessary settings and configurations to ensure accurate and timely document generation and submission, adhering to local regulations. For fiscalization in Sweden, EVA integrates with Infrasec to adhere to local regulations.

About Infrasec

Infrasec is a cloud-based service approved by the Swedish Tax Authority (Skatteverket) as a certified VAT registration provider. It operates through a VAT Control Unit, known in Swedish as "kontrollenhet."

When configured correctly, Infrasec ensures seamless synchronization of all transaction data from EVA Point-of-Sale stations to the tax control unit, maintaining compliance with tax regulations.

Special considerations

A few considerations need to be taken into account when it comes to compliancy in Sweden, as follows:

Local mode support

Local mode is currently not supported by EVA in Sweden. Activating local mode is done at your own discretion and risk. We strongly recommend conducting thorough testing of local mode before going live to ensure it aligns with your expectations.

If you require support for local mode, please submit a JIRA development ticket, namely a request for change.

Infrasec Offline Support

If Infrasec goes offline during a transaction, the order must include certain customer data to generate an invoice.

Note: Invoiced sales do not require registration with Infrasec (see special consideration note on B2B Invoiced Sales transaction below).

Required Customer Information for Invoicing

For B2C Transactions:

• Customer first name
• Customer last name
• Billing address:
  • Address 1
  • Zip code
  • City

For B2B Transactions:

• Company name
• VAT number
• Billing address:
  • Address 1
  • Zip code
  • City

Error Handling

When Infrasec is offline and you try to create a payment using EVA, you will encounter an error message: "Infrasec is unavailable, please attach customer information to continue the sale." along with which missing field(s) need to be completed to proceed with the transaction.

B2B Invoiced Sales Transactions

Under Swedish Tax Law, B2B invoiced sales transactions are not required to be registered on cash registers. Therefore, they are also exempt from registration on Infrasec. This means that instead of getting a fiscal receipt, a PDF invoice will be issued for B2B invoiced sales.

Invoiced sales refer to transactions where the seller extends credit to the buyer, allowing for deferred payment. Such transactions do not require recording in a cash register.

Unreferenced returns

Unreferenced returned orders are permitted (a return that is not linked to an original order sold via EVA).

However, when creating an unreferenced return, EVA will require you to enter the order number and sales date of the original sale to which this return will reference. If you are migrating from an old POS system, you can enter the order number and date from the receipt of the original sales order. This data is necessary to demonstrate to authorities that you are not simply returning items, which could be perceived as a sign of tax evasion.

Simplified invoices

Simplified invoices are essentially streamlined sales receipts that contain minimal information. Unlike a standard invoice, which lists comprehensive customer details such as name, billing address, and VAT number, a simplified invoice requires only a VAT number or Fiscal ID. This type of invoice is permissible only when the total order amount remains below a certain threshold. For Sweden, a simplified invoice would be issued if the order is below 4000 SEK and NIF / VAT is set.

Zero priced articles

In Sweden, fiscal printers cannot process sales of products priced at $0. These items are typically samples or promotional goods that would still require inventory tracking, despite being free to customers.

Products priced at $0 in the basket are not sent to the fiscal printer, and thus do not appear on the receipt.

However, the fiscal printer can apply 100% discounts to individual items or the entire order, allowing these transactions to be included on the fiscal receipt with the appropriate discounts noted.

Step-by-step configuration

This is a step-by-step guide to configurations that need to be performed within EVA for a compliant setup in Sweden. The steps should be followed in the same order as presented hereunder.

Step 1: Signing the POA

Reach out to New Black for to sign the POA. For that, please submit a ticket via support.

The POA will be signed by you and us. It provides Infrasec with the rights to use our data for registration purposes with Swedish tax authorities.

Step 2: Structure your company by means of OUs

The entire structure of your company, stores, e-com front ends and whatnot, can be configured by means of organization units. Please see Organization units for a thorough explanation on the benefits and practical steps of creating a hierarchical OU structure.

Companies

In your scenario, you likely already have an OU structure set-up, with a Container company at the top. Each country however, also needs its own specific company. This means that now that you're starting to operate in Sweden, you need to create a new company.

Later on you will have to add this company to each OU you create for Sweden.

For the company you create for Sweden specifically, please make sure the following fields are filled in:

• Name
• VAT Number (Momsregistreringsnummer or Momsnummer - sample: SE999999999999)
• Registration Number (Organisationsnummer - This is 10 digits, sample: 0123456789)
• Registration City
• Registration Country
• Address (VisitorAddress)
  • Country
  • ZipCode
  • City
  • Address 1

Sweden VAT number structure and sample

In Sweden, the VAT number is known as "Momsregistreringsnummer" or "VAT-nummer". The format is typically 12 characters, where "SE" is the country code followed by a 10-digit number. The last two digits are often "01" and serve as a checksum or identifier for the legal entity.

For example, a VAT number might look like this: SE123456789012.

Create your OUs

Creating country and (web)store OUs.

Country OU

First off: create your new Country type OU for Sweden.

While this OU requires you to set a Parent store, to indicate its place in the hierarchy, your Country OU does not require a Company.

(Web)Store OUs

With your country and country-specific company ready, you can start creating your OUs in Sweden. While these are likely certain to include Shops (physical stores) and WebShops (for your custom e-commerce front end(s)), many more OU types are possible.

Please see the Organization unit types list for an overview of possible OU types.

Make sure the following fields are filled in:

• Name
• Email address
• Address
  • Street
  • ZipCode
  • City
  • CountryID
• CompanyID (Make sure to select the company you've created)

Shop identifier on Infrasec

New Black will set the shop identifier on Infrasec for you. This number will be based on your OU ID.

Additional step for multiple stores

In scenarios where multiple organization units/stores operate in the same country, it's best to make a grouping. While you can also create groups by means of Organization unit sets, we advise making one as an (Container) OU instead. This will ease setting inheritance and make for a clear structure in your OU hierarchy.

1. The grouping can be done by creating a new organization unit of type Container + Country.
2. Once created, attach all your stores (organization units of type Store) under the new container for this country.

Step 3: Request Infrasec

As earlier mentioned, Infrasec is our integration partner for fiscalization in Sweden. To set up the integration, please submit a support ticket. In your ticket, include either the Container OU ID or the Store IDs, depending on your situation. We will promptly configure and update the necessary settings as outlined below:

Setting	Value	Organization unit	Description
Auditing:Sweden:InfrasecReceiptCertServerTrustPem:BlobGuid	-	Container	Certificate New Black uses to verify Infrasec’s identity
Auditing:Sweden:InfrasecReceiptCertPfx:Key	-	Container	Key for receipt API certificate
Auditing:Sweden:InfrasecReceiptCertPfx:BlobGuid	-	Container	Certificate in PFX form that New Black uses to verify Infrasec’s identity
Auditing:Sweden:InfrasecReceiptApiCertificate:Url	-	Container	Endpoint for the receipt synchronization
Auditing:Sweden:InfrasecEnrollmentCertServerTrustPem:BlobGuid	-	Container	Certificate New Black uses to verify Infrasec’s identity
Auditing:Sweden:InfrasecEnrollmentCertPfx:Key	-	Container	Key for the enrollment API certificate
Auditing:Sweden:InfrasecEnrollmentCertPfx:BlobGuid	-	Container	The certificate in PFX form for Infrasec’s station enrollment API
Auditing:Sweden:InfrasecApiCertificate:Url	-	Container	Endpoint for the point-of-sale synchronization
Auditing:Sweden:InfrasecApi:PosAuthorityCode	-	Container	Unique identifier for New Black provided by Infrasec

Step 4: Create stations

For the Organization Unit(s) of type Store where transactions will be performed, you'll need to create Station(s) for each (if applicable). Adding a station can be done by following the steps here.

When creating the Station(s), make sure the following fields are filled in:

• The underlying Organization Unit where the station will be used i.e. attached to the OU of type Store.
• The station name.
• The box This station is a fiscal station and will be used for transactions needs to be checked.
  
  

Successful and Unsuccessful Station Syncs with Infrasec & Deleting Stations

When syncing with Infrasec, check the Fiscal System ID field within the General Information card of the station. If this field is populated, the sync was successful. If it is empty, submit a ticket with the Station ID to request a resync.

Deleting a station without a Fiscal System ID will cause an error. For instructions on how to remove Fiscal stations in EVA, the Swedish Tax Authority, and to understand potential error messages, see Removing Fiscal Stations from EVA.

Step 5: Report Stations to the Swedish Tax Agency

Two Week Grace period for Reporting Stations to Swedish Tax Authority

You must report all cash registers that have successfully synced with Infrasec to the Swedish Tax Agency (Skatteverket) within two weeks of receiving the Fiscal System ID of the register/station.

After your store register(s)/station(s) are synced with Infrasec and where you've now obtained corresponding Fiscal system ID(s), please proceed to the Skatteverket portal to report those.

For more information and to perform your reporting, click here.

Step 6: Check payment types

For transaction reporting, EVA groups your payment types into a number of predefined categories (e.g. Cash, Credit, Voucher, Online, etc.). To perform transactions, ensure that all Payment types you offer in this country have a Payment Category defined. Payments are configured via the Admin Suite under the Payment methods chapter -> Payment Types -> Payment Category field.

Step 7: Settings for auditing provider and invoices

The following settings need to be added. This can be done via the Admin Suite under the Settings chapter.

Setting	Value	Organization unit	Description
Auditing:Provider	SWEDEN	Container	Sets the certified aspects
Auditing:Sweden:Tenant:Name	As desired. For the acceptance environment, add ACC at the end; for test environment, add TST at the end. For example, EvaACC or EvaTST	Container	Merchant name - Using the name of your company is recommended here.
Auditing:Sweden:Tenant:Code	Typically your company name. For the acceptance environment, add ACC at the end; for test environment, add TST at the end. For example, NewBlackACC or NewBlackTST	Container	Should be unique (Max. 5 characters)
Auditing:Sweden:Shop:Number	4-digit number based on OU ID. Note: Use 5 as prefix for acceptance environment and 6 as prefix for test environment. For example, 5001 or 6001.	Store/Shop OU	OU ID-based number prefixed with 0 to reach the 4 digits. For example OU ID = 48, becomes 0048. Note: that if you create a new OU after the initial configuration, this setting needs to be set on that newly created OU as well.
Auditing:Sweden:Shop:Name	If empty, defaults to the OU name in EVA. Note: Prefix the name with ACC for acceptance environments and TST for test environments. For example, ACC-Shop1 or TST-Shop1.	Store/Shop OU	Determines the store name in Infrasec.

Note: Matching Tenant Name with Tenant Code and Changes

• Ensure that both Tenant:Name and Tenant:Code are unique. If you edit the Tenant:Name, you must also use a new Tenant:Code.
• If you change the Company Name in EVA post initial setup, make sure to update the Tenant:Name setting to reflect the new name. Additionally, make sure to also update the Tenant:Code to ensure it remains unique across environments.

Note: Matching Shop/Store Name with Shop number and Changes

• Shop:Number and Shop Name must also both be unique. If you edit the name of one of your shops, you must also update the Shop:Number setting. Further, if you’re creating the same Shops with the same names on both TEST env and ACCEPTANCE environments, make sure you use the exact same value for the Shop:Number setting on each shop that has the same name on both environments.
• If a Shop/Store Name in EVA is changed, increment the Shop:Number setting to maintain uniqueness.

Setting for e-commerce

In Sweden, e-commerce sales are not subject to cash register requirements, so they are not recorded at Infrasec. However, we simplify the configuration and setup process. When the Auditing:Provider setting is set with a value SWEDEN on the e-commerce organization unit, EVA manages the invoice and stencil logic. Specifically, the CertifiedInvoice Stencil in PDF format covered under Step: Stencils is utilized for e-commerce transactions, and it shares the invoice number sequence with B2B invoices as depicted in the Invoice Chain / Invoice Sequence under the Ecom order flow.

Step 8 (optional): Auto open close financial period

This is an optional step where you can configure auto open and close of your financial period.

Step 9: Stencils

This step impacts what your certified invoices (thermal & PDF) will look like.

For setup instructions and additional information on Certified Invoices, please visit the Stencils for certified countries documentation page. To attach a certified invoice to an email, a separate stencil is necessary. You can find the configuration details for this stencil on the same page.

Sample PDF and Thermal Receipts

You can generate a preview of your PDF invoice or Thermal Receipt using the Stencil chapter. Remember, the order details in the preview will be substituted with the actual order information. Additionally, we advise printing a real PDF invoice and thermal receipt during your testing, and to not rely solely on this preview feature.

Stencil Preview Feature

Below is an example of the CertifiedInvoice template preview found in the Stencil chapter of Admin Suite.

Step 10: Validation & testing

Now is a good moment to validate and test your setup, as follows:

Validation

Once you're done with all configuration steps. Make sure to use the Validate audit configuration button to check if any compliance-related configurations or data is missing or successfully configured.

Testing

Start placing some orders and check the following:

• Check that thermal receipts include: SWEDEN.ControlUnitCode and Kontrolkod: SWEDEN.ControlCode.
• Check that the PDF Certified invoice looks similar to the sample stencil provided (check step for stencils).
• Check that all station are successfully created and reported to the Swedish tax authority (check steps for create stations and report stations).
  
  

Step 11: X/Z reports

Reports are essential for daily financial reconciliation, inventory management, and ensuring accuracy in sales tracking and reporting.

In EVA we make the differentiation between two types of reports: X report and Z report.

• X report (Middle of Day report): Summary statement of the day's sales totals without any notion of closing or generation of cumulative data.

  • X reports can be generated at any time during the day without affecting the ongoing totals.
  • It provides a snapshot of sales, VAT collected, breakdown of payment methods, date and time, without resetting counters.
  • It is not possible to re-generate a specific X report as they are snapshots of the current state.
  • The X report is station specific.

• Z report (End of Day report): Definitive summary statement of sales totals associated with a daily closing and the generation of daily cumulative data.

  • Z reports are generated by closing of the financial period in EVA, typically at the end of a business day.
  • Summaries of certain data, and therefore don't contain any detailed data at transactions level. The Z total reports and all data supporting the reports will need to be retained.
  • It provides a summary of total sales, VAT collected, the breakdown of payment methods, date, time and sequential number
  • The Z report is station specific.

How to generate the reports

EVA can generate a daily X and Z reports by closing the Financial Period, or via the terminal report service: GenerateTerminalReport. The Event ledger in EVA will show all the generated reports.

Each report will be tagged with a unique, sequential identification number that follows a chronological order. It maintains a database of these reports for the current year (or financial period) and archives the data from the six preceding years (or financial periods) that have been concluded.

How to set up the Terminal Report stencil

When it comes to X/Z reports, a stencil called TerminalReport is used.

Here is the stencil content

<report>
    <scope bold="true" align="center" size="1,1">
        {{>Document.Type == 0 ? 'X Report' : 'Z Report'}} #{{>Number}}
    </scope>
    
    <scope align="center" font="FontB" tabs="21">
        {#partial TerminalReportHeader}
    </scope>
    
    <feed amount="32"/>
    
    Date: {{:~date(Document.CreationTime, 'DD.MM.YYYY', 'fr-FR', 'Europe/Paris')}}
      Heure: {{:~date(Document.CreationTime, 'HH:mm:ss', 'fr-FR', 'Europe/Paris')}}
    
    <feed amount="32"/>

    <grid positions="0, 30">
        <row>
            <col width="20">
                <bold>Changement</bold>
            </col>
            <col>{{:~currency(Document.Change, ~root.CurrencyID)}}</col>
        </row>
        <row>
            <col width="20">
                <bold>Ouverture du tiroir-caisse</bold>
            </col>
            <col>{{>Document.CashDrawerOpenings}}</col>
        </row>

        <row>
            <col width="20">
                <bold>Paiements</bold>
            </col>
            <col>{{: Document.Payments ? Document.Payments.length : 0}}</col>
        </row>

        {{for Document.Payments}}
        <row>
            <col width="20">
                {{>Type.Name}} ({{>Count}})
            </col>
            <col>{{:~currency(Amount, ~root.CurrencyID)}}</col>
        </row>
        {{/for}}

        <row>
            <col width="20">
                <bold>Taxes</bold>
            </col>
            <col>{{: Document.Taxes ? Document.Taxes.length : 0}}</col>
        </row>   

        {{for Document.Taxes}}
        <row>
            <col width="20">
                {{>Name}} ({{:~rateToPercentage(Rate)}})
            </col>
            <col>{{:~currency(Amount, ~root.CurrencyID)}}</col>
        </row>        
        {{/for}}

        <row>
            <col width="20">
                <bold>Paiements par employé</bold>
            </col>
            <col>{{: Document.PaymentsPerUser ? Document.PaymentsPerUser.length : 0}}</col>
        </row>

        {{if Document.PaymentsPerUser}}
        {{for Document.PaymentsPerUser}}
        <row>
            <col width="20">
                Employé(e) {{>UserID}} ({{>Count}})
            </col>
            <col>{{:~currency(Amount, ~root.CurrencyID)}} ({{>Description}})</col>
        </row>
        {{/for}}    
        {{/if}}

        <row>
            <col width="20">
                <bold>Groupes de produits</bold>
            </col>
            <col>{{>Document.ProductGroups.length}}</col>
        </row>

        {{for Document.ProductGroups}}
        <row>
            <col width="20">
                {{>Code}} ({{>Count}})
            </col>
            <col>{{:~currency(Amount, ~root.CurrencyID)}}</col>
        </row>
        {{/for}}

        <row>
            <col width="20">
                <bold>Nomber de remise</bold>
            </col>
            <col>{{>Document.DiscountCount}}</col>
        </row>
        <row>
            <col width="20">
                <bold>Total des remises</bold>
            </col>
            <col>{{:~currency(Document.TotalDiscounts, ~root.CurrencyID)}}</col>
        </row>     

        <row>
            <col width="20">
                <bold>Nombre de retours</bold>
            </col>
            <col>{{>Document.ReturnCount}}</col>
        </row>
        <row>
            <col width="20">
                <bold>Total des retours</bold>
            </col>
            <col>{{:~currency(Document.TotalReturnsAmount, ~root.CurrencyID)}}</col>
        </row> 

        <row>
            <col width="20">
                <bold>Nomber d'exemplaires</bold>
            </col>
            <col>{{>Document.CopyReceiptsPrinted}}</col>
        </row>
        <row>
            <col width="20">
                <bold>Total d'exemplaires</bold>
            </col>
            <col>{{:~currency(Document.TotalCopyReceiptsAmount, ~root.CurrencyID)}}</col>
        </row>      

        {{* Grand totals *}}
        <row>
            <col width="20">
                <bold>Total général (paiement en espèces)</bold>
            </col>
            <col>{{:~currency(Document.GrandTotalCash, ~root.CurrencyID)}}</col>
        </row>
        <row>
            <col width="20">
                <bold>Total général</bold>
            </col>
            <col>{{:~currency(Document.GrandTotal, ~root.CurrencyID)}}</col>
        </row>        
        <row>
            <col width="20">
                <bold>Total général (retours)</bold>
            </col>
            <col>{{:~currency(Document.GrandTotalReturns, ~root.CurrencyID)}}</col>
        </row>        
        <row>
            <col width="20">
                <bold>Total général (HT)</bold>
            </col>
            <col>{{:~currency(Document.GrandTotalNet, ~root.CurrencyID)}}</col>
        </row>        
    </grid>

    <feed amount="32"/>
    
    Terminal: {{>TerminalCode}}
    
    <feed amount="16"/>

    <scope align="center">
        <qrcode data="{{:ZippedSignature}}" size="6"/>
    </scope>

    <feed amount="16"/>
</report>        

Automated printing Z report(s)

Using a setting called Auditing:PrintTerminalReport and a value true, accompanied by the Terminal Report stencil, an automatic print of the Z report will be made once a financial period is closed. If you have multiple stations in you store, a print of all Z reports pertaining to the station you're logged into when closing your financial period will be printed.

Printer configurations

Beware that printer configurations for the respective stations need to exist in order for the Z reports to successfully print.