DBA Use case definition

Pilot scenarios

• Pilot scenario DBA1: USP.gv.at: USP (Business service portal) includes several services (starting a business online) that are not restricted to Austrian companies. In order to qualify for the service, the company must provide the necessary data and needs an entry in one of the registers. The stored company data must be kept up to date. This scenario entails a non-Austrian company that applies for a service carried out by usp.gv.at. Currently, this is a semi-automated process, due to a necessary application process to identify organisation and the approval of the powers (of representation). In the pilot process, the company can apply for these services through an easy online form, which will trigger an automatic registration to most of Austria´s online services. Additionally, as best-effort, Austria will make this application process fully automated, so the company does not have to supply information to USP that is already known to a data provider in another Member State (the ‘native’ country of the business) in application of the Once-Only Principle. In either case, USP is able to retrieve this information from the data provider and keep the information up to date. The minimum goal of the scenario is to digitalise this process. The maximum goal is to implement a fully automated process.
• Pilot scenario DBA4: MijnRVO.nl: RVO offers several services for companies that are not restricted to Dutch companies. In order to qualify for the service, the company must provide the necessary data. Besides the specific data required to qualify for the service, RVO also requires general data of the company itself, for identification, communication and compliance purposes. RVO stores this company data in a central (‘customer’) registry that is used for most RVO services. The stored company data must be kept up to date. This scenario entails a non-Dutch company that applies for a service carried out by RVO.nl. In this process, the company does not have to supply information to RVO that is already known to the data provider in a Member State (the ‘native’ country of the business) in application of the Once-Only Principle. RVO.nl is able to retrieve this information from the data provider and keep the information up to date.
• Pilot scenario DBA5: Verksamt.se (PSC): Companies that want to do business in Sweden will be registered by the Swedish Companies Registration Office through the Swedish Point of Single Contact Verksamt.se. The portal presents companies with information and e-services. There is no information stored within the portal. The source of company information will be the respective authority. There is an opportunity to do a tax registration, with underlying processes such as registering the company at Skatteverket, registering as an employer, paying VAT, applying for F-tax and so on. It is also possible to register a branch of a foreign company, by using the service provided by Bolagsverket. Verksamt.se is designed to provide a unified process for the foreign company to be able to register a branch and then make a tax registration in Sweden, depending on how the company intends to conduct business operations in Sweden. Verksamt.se also supports foreign companies, whether they conduct business from a permanent establishment in Sweden or only want to register for tax purpose (not register a branch), for selected processes e.g. to register as an employer or F-tax. F-tax can be applied for without liability to pay income tax, but serves as a proof that the company has no tax liabilities in the country of registration and is therefore considered serious.
• Pilot scenario DBA6: eService Layer at portal.onrc.ro: Companies wishing to do business in Romania will be registered by the National Trade Register Office. The registration of the company of a single trader, company or branch of a foreign company is done using the online service portal eService Layer at portal.onrc.ro and leads to the registration in the register of Romanian companies (ONRC). The registration also leads to registration with the Romanian tax agency - ANAF. As part of the registration with the tax agency, the company can (if applicable) register the permanent unit and register for VAT.

Use cases

1. Use case 1: Starting a business in another Member State. At the core of this use case is the fulfilment of procedural obligations to do business in another Member State, especially the initial registration of a company at an eProcedure portal (AT, NL and RO pilot scenarios), opening a branch and the assessment of tax duties in the destination Member State (in the Swedish pilot scenario). In this use case, a company representative authenticates to the eProcedure portal, registers the company at the portal and applies for a service.
2. Use case 2: Doing business in another Member State. This use case focusses at assessing the consequence for active eServices in case of a business event, e.g. company goes bankrupt, company stops it’s activities, company merges, etc. The data consumer may subscribe to notifications on selected business events. In case such an event occurs, the data provider notifies the data consumer. The data consumer needs to assess the relevance of the notification. It can then for example request the updated data from the data provider or decide it doesn’t need any additional data. Furthermore, the data consumer may intervene in an active eService (e.g. stop periodical grants or impose a tax obligation). The data consumer may also use the notifications as input to a general fraud prevention and protection procedure.

Pilot scenario #	Pilot scenario short name	Use case to pilot
		UC1: starting a business in another Member State	UC2: Doing business in another Member State
DBA1	USP.gv.at	x
DBA4	MijnRVO.nl	x	x
DBA5	Verksamt.se (PSC)	x	x
DBA6	eService Layer at portal.onrc.ro	x	x

Interaction patterns

The use cases implement three interaction patterns:

1. The intermediation pattern: for fetching company data at the request of the user from the business register directly.
2. The subscription and notification pattern: for allowing data consumers to subscribe to updates on company data and to receive notifications of changes in company data.
3. The lookup pattern: for providing a light weight alternative to the intermediation pattern for fetching (possibly updated) company data from business registers with direct service calls. This pattern focusses on high frequency, highly standardised data requests to data sources which the data consumer is familiar to.

The diagram below shows the mapping of the use cases to the interaction patterns.