Account structure in Aera

Your account structure mirrors how your business is organised. It decides where the money goes, who receives invoices and who can see and administer what in the Aera portal. It works the same way for in-store and online payments.

Aera's onboarding team sets up the structure together with you.

How it's organised

An Aera account can have up to 5 levels, which together describe any small or large enterprise. Customer and Merchant are required levels, and the rest are optional groups.

In addition every account must have one or more Legal Owners, which is a role assigned to a level of your choosing. The legal owner has to be a company with its own organisation number, and is the one who receives settlements for everything below it.

Payment Points like terminals or hosted checkouts are always linked to the merchant level. Illustrated:

flowchart TD
  C("<b>Customer</b><br/>Required") --> V("<b>Vertical</b><br/>Optional")--> CH("<b>Chain</b><br/>Optional") --> SC("<b>Sub-chain</b><br/>Optional") --> M("<b>Merchant</b><br/>Required")
  M --> T(["<b>Terminals and HPPs</b>"])
  LO("<b>Legal owner</b><br/>Required role")
  LO -. "assigned to" .-> C
  LO -. "or assigned to" .-> V
  LO -. "or assigned to" .-> CH
  LO -. "or assigned to" .-> SC
  LO -. "or assigned to" .-> M
  style V stroke-dasharray: 5 5
  style CH stroke-dasharray: 5 5
  style SC stroke-dasharray: 5 5
  classDef pay fill:#EEF0FF,stroke:#6E62E5,color:#241A6B
  class T pay

Note that the Legal owner role can be assigned to entities at all levels, wherever the company's ownership starts. Subsequent levels inherit the legal owner from above, meaning all settlements will go to the same Legal owner. For complex customers it is normal to have multiple legal owners, for example one per chain.

The examples under Aera for Merchants and Aera for Partners below show how.

What belongs where

Aera for Merchants

With Aera for Merchants, your business or umbrella organisation is the Customer level. You will utilize the optional levels, such as verticals and chains, to ensure settlements are paid to the right company, that reports have the correct structure, and that portal users get the correct administration permissions. Finally, your stores and/or webshops are set up at the Merchant level.

Example 1: One company running both in-store and online sales

Example Bakery Inc. has three stores (merchants). Bakery Brussels has only in-store sales, Bakery Antwerp has both in-store sales and a webshop, and BakeryWeb is a pure webshop.

In this case Example Bakery Inc. opted to set up two verticals to separate pure online from in-store sales.

---
config:
  theme: base
  themeVariables:
    primaryColor: "#fdfbf5"
    primaryBorderColor: "#CFD4DC"
    primaryTextColor: "#1D2939"
    secondaryColor: "#F2F4F7"
    tertiaryColor: "#F8F9FB"
    lineColor: "#98A2B3"
    clusterBkg: "#F7F6FE"
    clusterBorder: "#D6D0F7"
    titleColor: "#3E2F93"
    edgeLabelBackground: "#fdfbf5"
  flowchart:
    curve: basis
    padding: 14
    nodeSpacing: 36
    rankSpacing: 44
---
flowchart TD
  
  subgraph LO ["<b>Legal owner</b>"]
    C("<b>Customer</b><br/>Example Bakery Inc.")
  end
  LO --> BW("<b>Vertical</b><br/>Bakery Web Sales</b>")
  LO --> BS("<b>Vertical</b><br/>Bakery Shops</b>")
  BS --> M1("<b>Merchant</b><br/>Bakery Brussels")
  BS --> M2("<b>Merchant</b><br/>Bakery Antwerp")
  BW --> M3("<b>Merchant</b><br/>BakeryWeb.com")
  M1 --> T1(["Terminal 1"])
  M1 --> T2(["Terminal 2"])
  M2 --> T3(["Terminal 1"])
  M2 --> T4(["Terminal 2"])
  M2 --> H1(["HPP 1"])
  M3 --> H3(["HPP 1"])
  M3 --> H4(["HPP 2"])
  classDef pay fill:#EEF0FF,stroke:#6E62E5,color:#241A6B
  class T1,T2,T3,T4,H1,H2,H3,H4 pay

• Settlements: Everything is paid to the legal owner, which in this case is Example Bakery Inc. Note that the payout still can be split into different bank accounts, e.g. one for each vertical. But all bank accounts must be by Example Bakery Inc.
• Payment points: BakeryWeb.com has set up two HPPs for different checkout flows - one for their B2B webshop and one for their B2C webshop. Bakery Brussels has two terminals. Bakery Antwerp has both terminals and an HPP for a booking site they operate.
• No chains or sub-chains needed: With one company and a few stores, chains add nothing today. Note that they can be added later if the enterprise grows.
• Access management: Web administrators at Bakeryweb.com is given access to the vertical Bakery Web Sales. In this way they can see sales, and control the appearance and payment methods in their two HPPs. However, they cannot see or control anything related to the other vertical Bakery Shops.
• Invoices: The billing for Aera services is sent to the two verticals, as it works great for Bakery Inc. internal cost centre and P&L setup.

Example 2: Group with multiple Legal Owners, regional companies and franchise stores

ExGrocery Group runs the chains ExConvenience and ExMarket. ExMarket consists of a regional company that owns two Berlin stores, and a franchise arm operates two stores. ExConvenience is set up as individual merchants.

---
config:
  theme: base
  themeVariables:
    primaryColor: "#fdfbf5"
    primaryBorderColor: "#CFD4DC"
    primaryTextColor: "#1D2939"
    secondaryColor: "#F2F4F7"
    tertiaryColor: "#F8F9FB"
    lineColor: "#98A2B3"
    clusterBkg: "#F7F6FE"
    clusterBorder: "#D6D0F7"
    titleColor: "#3E2F93"
    edgeLabelBackground: "#fdfbf5"
  flowchart:
    curve: basis
    padding: 14
    nodeSpacing: 36
    rankSpacing: 44
---
flowchart TD
  C("<b>Customer</b><br/>ExGrocery Group")
  
  subgraph LO1 ["<b>Legal owner 1</b>"]
    CH1("<b>Chain</b><br/>ExConvenience")
  end
    
  subgraph LO2 ["<b>Legal owner 2</b>"]
    CH2("<b>Chain</b><br/>ExMarket")
  end
  C --> LO1   
  C --> LO2
  LO2 --> SC("<b>Sub-chain</b><br/>ExMarket Berlin")
  SC --> M1("<b>Merchant</b><br/>ExMarket Brandenburg")
  SC --> M2("<b>Merchant</b><br/>ExMarket Alexanderplatz")
  LO2 --> SC2("<b>Sub-chain</b><br/>Franchises")
  SC2 --> M3("<b>Merchant</b><br/>ExMarket Franchise1")
  SC2 --> M4("<b>Merchant</b><br/>ExMarket Franchise2")
  LO1 --> M5("<b>Merchant</b><br/>Exconvenience1")
  LO1 --> M6("<b>Merchant</b><br/>Exconvenience2")

• Settlements: Two separate payouts goes to ExMarket and ExConvenience.
• Chains and sub-chains needed: As group complexity grows with regions, franchises and chains, these optional grouping functions provides value to the setup.
• Access management: As the breakdown follows the structure of the group, there is great flexibility to ensure employees working for the different organisations only see and control what is relevant for them.
• Invoices: The billing for Aera services is sent to the two verticals, and is set up to meet Bakery Inc.'s internal cost-centre and P&L structures.