Intercompany Accounting – Settlements

Intercompany accounting (or settlements) is the heart of chain financial operations. When a franchise chain consists of multiple legal entities (different ABs with own org numbers), economic flows arise between them – and these must be correctly reconciled in accounting. Vendion automates this flow.

When do intercompany transactions arise?

Common cases:

1. Chain gift cards: Card sold at Company A, redeemed at Company B → B has receivable on A for redeemed value
2. Pooled loyalty (future): Points earned at A, redeemed at B → revenue sharing
3. Master franchise royalties (future): Unit pays royalty to HQ
4. Shared purchases (future): Chain has central supplier billing units

In MVP, it's primarily chain gift cards that trigger intercompany.

Where does settlement happen?

At /chain/:slug/bokforing – the chain's intercompany page. Page only visible to chain admins with accounting rights.

What the page shows

1. Pending transactions – unreconciled intercompany transactions:

1. Reconciled transactions – completed, historical

2. Monthly settlement summary:

   • Total outstanding per company pair
   • Net balance (who owes whom)
   • Last settlement

3. Export buttons: SIE, CSV, PDF

How the transaction is recorded

Each intercompany transaction contains:

• Type – gift card redemption, royalty, revenue share, etc.
• Issuing unit + org number
• Redeeming unit + org number
• Amount
• Status – pending, both posted, reconciled, disputed
• Created date and reconciled date

Accounting logic per transaction

Example: 400 SEK redeemed at Company A, issued by HQ.

At A (redeeming):

At HQ (issuing):

At month-end settlement

When HQ pays A 400 SEK (via bank):

And at A:

Status on the transaction moves from "pending" → "reconciled".

Auto-vouchers at Z-report

Each restaurant's daily Z-report triggers auto voucher generation:

1. System looks up pending intercompany involving this unit
2. Creates accounting vouchers in a dedicated intercompany series
3. Applies debit/credit per type and direction
4. Voucher becomes part of unit's daily run in accounting

Example: Month-end April 2026

Scenario: 5 pending transactions in April:

• 3 cards redeemed at Company A (total 2,400 SEK)
• 2 cards redeemed at Company B (total 1,800 SEK)
• All issued by HQ

At month-end (typ. April 30 via scheduled run):

1. Aggregated per company pair
2. HQ owes A: 2,400 SEK
3. HQ owes B: 1,800 SEK
4. Total outstanding: 4,200 SEK

Chain owner:

1. Goes to /chain/:slug/bokforing
2. Sees pending list and sums
3. Clicks "Export SIE" per unit
4. Sends SIE files to bookkeeper or imports to Fortnox/Visma
5. Once the bank payments have gone through → marks the period as settled (see below)

How you mark a period as settled

The settlement view shows the net per company pair: who owes whom, and how much. Once you have actually transferred the money, you mark the period:

1. Pick the period (e.g. all of April)
2. Read off the net per company pair
3. Click Mark as settled on the pair you paid

The system handles the paperwork — you handle the payment. We never mark anything as settled automatically: a cron job claiming money has changed hands without knowing it is exactly the wrong way to be wrong in accounting.

Four rules that protect you

• Only posted rows can be settled. A row that has not yet reached the books (pending) is skipped — marking it would close a period that is still open. The order is always posted before settled.
• A disputed row is not silenced. If you have flagged a row as disputed, a period run leaves it alone. It must be handled separately.
• Double-clicking does no harm. Run the same period twice and nothing is settled the second time, and the timestamp does not move. Two people can click at once without it looking like the money changed hands twice.
• Only the pair and period you chose. Rows outside the period, on another company pair, or in another chain are never touched.

Who is allowed to do it?

Settling requires the permission to view intercompany. Being a chain member is not enough — the permission must be in your group. The check sits in the database, not just in the button.

What is recorded?

Every settled row records who marked it, when, which period was meant, and any note you added (e.g. Bank transfer 2026-04-30). That is your audit trail when the accountant asks how the settlement was done.

BAS accounts – customizable

Default accounts:

• 1660 – Receivable from group companies
• 2860 – Payable to group companies

Customizable per chain in /chain/:slug/installningar:

• Receivable account: [input]
• Payable account: [input]

Changes apply only to future vouchers – not already settled.

Export formats

SIE: Swedish standard for accounting exchange. Compatible with Fortnox, Visma, Björn Lundén, etc. File contains all vouchers for chosen period.

CSV: Raw export with columns: voucher date, account, debit, credit, description, reference, transaction ID. Can be imported in Excel or any system.

PDF: Human-readable report for bookkeeper – summary + details.

Disputed status

If a unit disputes a transaction (e.g. "we haven't received the money yet"):

1. Mark as "disputed" in UI
2. Add comment
3. Transaction moves out of pending list until resolved
4. Requires manual review by chain admin

Future improvements

• Automatic netting: if HQ owes A 2,400 and A owes HQ 800, net to 1,600
• Batch payments: one-click bank payment via Swish Business or direct debit
• Fortnox/Visma integration: push vouchers automatically (planned)
• Batch settlement vouchers: one combined voucher per month instead of per transaction

Legal – Sweden

Per Swedish tax law:

• Companies must correctly book intercompany transactions
• Intra-group transactions have special VAT rules (VAT on intra-group sales)
• Outstanding receivables and payables must be reported in annual accounts
• Over 5 MSEK intercompany flow per year may require special reporting

Vendion's vouchers follow Swedish practice but don't replace bookkeeper advice – contact your certified auditor for company-specific handling.

Next step: Read Chain Bookkeeping – Multiple Legal Entities for broader accounting context (also deeper coverage in the Bookkeeping module).