e-copedia hjælpecenter

Products, productGroups and Sales Accounts when Invoicing

Sidst opdateret:
Skrevet af Charles J

When creating invoices through the e-conomic API, it is important to understand the relationship between products, productGroups, VAT zones, and accounts.

See productsAPI documentation here.

The account used when an invoice is booked is not selected directly on the invoice. Instead, e-conomic determines the appropriate sales account from the setup of the product used on each invoice line.

1. Products belong to productGroups

Every product in e-conomic belongs to a productGroup.

When retrieving a product through the Products API, this relationship is represented by the productGroupId:

Example from request

{
"productNumber": "PRODUCT-1",
"productGroupId": 1,
"name": "Example product",
"salesPrice": 100
}

The product itself contains information such as its product number, name, sales price and the ID of the product group it belongs to.

2. The productGroup controls the accounting setup

The productGroup determines how sales of products belonging to that group should be posted.

Among other things, a productGroup can define the sales accounts to use for different VAT zones.

For example, you could have two Product Groups configured like this:

Product Group 1 – Domestic sales account: {salesAccount A}
Product Group 2 – Domestic sales account: {salesAccount B}

Products assigned to productGroup 1 would then use the accounting setup of that group, while products assigned to productGroup 2 would use the setup of productGroup 2.

Product groups as a whole are used to control how revenue is posted on accounts.

3. VAT zone also determines which Sales Account is used

There is one additional part of the relationship which is the VAT zone.

A productGroup can contain several sales-accounts depending on the selected VAT zone on the customer/invoice.

Example of the flow:

1. Product in a productGroup with accounts setup for specific VAT zone
2. Customer is set on an Invoice with a selected VAT zone
3. Corresponding Sales Account is used from the productGroup

For example, if the invoice uses the domestic VAT zone, e-conomic uses the sales account configured for domestic sales on that Product Group.

This allows the same Product Group to have different accounting behavior depending on the VAT zone of the sale.

4. Creating the Invoice

When creating an invoice through the API, the invoice line references the product being sold.


Example:

{
"lines": [
{
"product": {
"productNumber": "PRODUCT-1"
},
"quantity": 1,
"unitNetPrice": 100
}
]
}

You do not specify the revenue account directly on the invoice line.

Instead, e-conomic can follow the configuration already established in the agreement. The accounting configuration is therefore kept separately from the invoice itself.

5. Separating revenue between different types of sales

This is particularly useful if an integration needs sales to be posted to different revenue accounts.

Imagine a company operates two webshops:

Webshop A → Revenue account {salesAccount A}
Webshop B → Revenue account {salesAccount B}

The integration cannot simply send:

{ "salesAccount": {salesAccount}}

on an invoice to decide where the revenue should be posted.

Instead, the appropriate Product Group setup needs to exist in e-conomic.

For example:

PRODUCT-A
Product Group A
Sales account {salesAccount A}

PRODUCT-B
Product Group B
Sales account {salesAccount B}

When those products are subsequently used on invoice lines, their respective Product Groups determine the accounting setup.

Important consideration when the same product is sold through multiple channels

If the same product needs to post revenue differently depending on where it was sold, this needs to be considered when designing the product structure.

The invoice itself cannot override the Product Group's sales-account configuration simply because the order originated from a different webshop or sales channel.

The e-conomic agreement therefore needs a Product/Product Group setup that represents the required accounting behavior. An example would be handling the same product via 2 different products + productGroups.

Obs

⭐ Exactly how the company wants to structure their productGroups should ultimately be decided by the customer or their accountant, as this determines how the revenue is represented in their accounts.

Var denne artikel nyttig?