Checkout-Based Promotional Settlement by Asseco Platform: a settlement module powered by Trade Data Hub and Trade Terms & Settlement — receipt-level verification of trade promotion execution between FMCG producers and retailers.
Checkout-Based Promotional Settlement
Trade promo settlement on receipt data, not the retailer’s declaration.
Powered by Trade Data Hub and Trade Terms & Settlement. Every receipt from your settlement retailers is checked against your active promotion catalogue. Refund reports rest on transactional data, not the retailer’s monthly declaration.
Trusted by the world’s leading FMCG brands
Trade promo settlement runs on the retailer’s report. Your settlement is only as good as their declaration.
You build the promotion. The retailer executes it. The retailer tells you how much you owe. You approve the refund payment from the same retailer’s own report — with no way to verify which stores executed, which didn’t, and whether the mechanic actually triggered at the till.
Without receipt-level verification
- ✕Settlement based on the retailer’s monthly declaration — not your own data
- ✕No store-level visibility — you cannot tell which placement executed as defined
- ✕Bonus payments approved on numbers you cannot audit transaction by transaction
- ✕Buyer negotiations run on two conflicting reports — producer’s and retailer’s
- ✕Manual receipt sampling, when attempted, takes analyst-weeks per settlement period
With Asseco Checkout-Based Settlement
- ✓Every receipt scanned daily — every promotion mechanic detected automatically
- ✓Store-level visibility: which store executed the promotion as defined — and which did not
- ✓Refund report with audit trail down to the individual transaction
- ✓Buyer negotiation starts from the same dataset on both sides of the table
- ✓Settlement period closes in hours, not weeks — automated end-to-end
Three steps from active promotion to settled refund — every receipt verified.
Asseco Checkout-Based Promotional Settlement runs on POS receipt data from your retailers. Trade Data Hub pulls the data daily, Trade Terms & Settlement detects the promotion mechanic on each receipt, and the refund report lands in your ERP — grounded in transaction-level audit trail.
Retailer onboarding & data acquisition
Trade Data Hub connects to each retailer’s POS data feed — SFTP, HTTPS or API, in the retailer’s native format. The integration team builds the SKU mapping that resolves “short EAN” and retailer-specific product codes, and a store dictionary that maps retailer → branch → individual point of sale. Daily reconciliation, deduplication and data-quality flags run automatically.
- →POS data feed per retailer — SFTP, HTTPS, API in native format
- →SKU mapping — resolves “short EAN” and retailer product codes
- →Store dictionary — retailer, branch and point-of-sale hierarchy
Daily promo detection on receipts
Every receipt is passed through the promotion detector in Trade Terms & Settlement. The system identifies your SKUs, verifies the conditions of each active promotion — price, multi-buy, threshold, seasonal window, bundle, voucher — and flags transactions that meet the mechanic. The cycle is next-day: a sale at the till today is verified in your settlement system tomorrow morning, with the mechanic identified at the transaction level.
- →6 promotion mechanics detected out-of-the-box
- →Next-day cycle — transaction today, verified tomorrow morning
- →All active promotions verified in parallel — no manual split between campaigns
Settlement report & ERP handoff
At settlement period close, Trade Terms & Settlement generates the refund report: quantity, value and refund due per promotion, per store and per retailer — with audit trail down to the individual receipt. Export the report as XLSX, PDF or push directly through API to your ERP. Producer approves the report and routes it to finance through the existing accounts-payable workflow.
- →Refund report — per promotion, per store, per retailer
- →Audit trail — down to the individual transaction
- →Export to ERP — XLSX, PDF or direct API
Four reasons FMCG finance teams want settlement on receipt data — not on retailer reports.
Four capabilities that turn trade promotion settlement from a quarterly negotiation into an audit-grade process — with every refund traceable to the transaction.
Independent verification
Stop paying bonus on the retailer’s own declaration. Every transaction has its own audit trail in the receipt — eligibility, mechanic and refund value computed on transactional data, not on what the retailer chose to report. Negotiations begin from the same dataset, not from two conflicting statements.
Bargaining power
Same data on both sides of the table. Buyer meetings shift from estimation to evidence: which stores executed the mechanic as defined, which did not, on which days, with what value. The conversation becomes operational, not declarative.
Audit trail for trade spend
Each refund payment is supported by a document at the individual receipt level — with granularity down to the store and the SKU. Internal controls, finance approval and compliance requirements for trade-spend accruals all rest on transactional source data.
Every active promotion verified in parallel
Each transaction is verified independently against every active promotion. Producers running campaigns across multiple retailers in parallel settle them all in a single cycle, with no manual split between mechanics, segments or retailers.
From the receipt at the till to the refund line in your ERP.
Every refund value is built from transactional data — receipt by receipt, mechanic by mechanic, store by store. The formula below shows the path from a single till transaction to the line item your finance team approves.
From receipt to refund
Receipt arrives
Store, SKU, quantity, price, timestamp — pulled next-day by Trade Data Hub from the retailer’s POS feed.
Detection & eligibility
The detector matches your SKUs (EAN, including “short EAN” resolution) and checks the conditions of each active promotion in parallel.
Eligible value & refund per transaction
For each eligible transaction: eligible value = price × quantity, then refund per transaction = eligible value × rebate % or fixed amount.
Aggregation & settlement period close
Refund is summed per promotion, per store, per retailer and per settlement period — ready for export to ERP.
How the refund is calculated
Aggregation: each transaction is checked independently against every active promotion. Aggregation runs per promotion, per store, per retailer and per settlement period — one transaction can be eligible for multiple promotions in parallel.
Settlement report — output fields
| Quantity | Units of SKU meeting promotion conditions |
| Value | Transaction value — price × quantity |
| Stores | Number of stores with eligible sales |
| Receipts | Number of receipts with the mechanic triggered |
| Refund due | Computed bonus payable to the retailer |
| Format | XLSX · PDF · API to ERP |
Beyond your receipts — your share of category, from the same feed.
Receipts cover your SKUs — what sold and which transactions were eligible for promotion. Many retailers also report category-level totals in the same data feed: total Beer, total Spirits, total Confectionery per network or store. One integration, three layers of intelligence.
Layer 1 · receipts
Your SKU sales
Every transaction with your products — already extracted from receipts for promotion settlement. Quantity, value, store, timestamp, mechanic flag.
Layer 2 · category totals
Category sales from the retailer
Total Beer, total Spirits, total Confectionery — aggregate values reported by the retailer at network or store level, in the same daily feed.
Layer 3 · share of category
Your sales vs competition
Computed automatically: your sales ÷ category total. Compare share by retailer, channel, region and period — against the rest of the category.
Example — share of category by retailer, month
| Category | Your sales | Total category | Your share |
|---|---|---|---|
| Beer | 4.20M | 18.50M | 22.7% |
| Cider | 1.10M | 3.20M | 34.3% |
| Spirits | 2.80M | 14.00M | 20.0% |
Category-level reporting is available when the retailer’s data feed includes category totals. The exact scope is confirmed during data integration setup.
What changes when settlement runs on the receipt — not on the retailer’s report.
Three outcomes that consistently follow when trade promotion settlement moves from manual reconciliation of retailer declarations to receipt-level verification on POS data.
Days → Hours
Settlement period close
From manual reconciliation of retailer declarations to an automated daily report — same data, computed end-to-end
All campaigns
Verified in parallel
Every receipt checked against every active promotion — no manual split between mechanics or retailers
0
Manual receipt sampling
Every transaction in the settlement period is verified — not a statistical sample, not a retailer declaration
From retailer kick-off to first refund report: up to 12 weeks per retailer.
Each retailer is a separate integration project — with its own ERP, its own data export logic and its own product coding conventions. Asseco runs the integration end-to-end with our own implementation team of 160+ specialists, refined across 170+ FMCG implementations.
Retailer kick-off
Scope, formats, technical contact and sample data agreed with the retailer
POS interface build
Retailer prepares the receipt export interface on its side — typically the longest step, dependent on retailer IT priorities
SKU & store mapping
Producer SKUs mapped to retailer codes, store hierarchy modeled, “short EAN” resolved (in parallel with step 02)
Detector configuration
First promotions configured in the detector, tested on historical week of data, mapping corrections finalised
Go-live & first cycle
First refund report generated automatically, validated with producer finance, full production cycle running
Total per retailer: up to 12 weeks end-to-end, with steps 02 and 03 typically running in parallel. After the first retailer is integrated, subsequent retailers are faster — detector templates and store-mapping conventions are reused.
Which analysts and standards recognise Asseco Platform for trade execution?
Independent recognition to support your internal business case.
Settlement engineered around FMCG operations — not assembled from generic trade-promo features.
Three things that set checkout-based settlement at Asseco apart from a horizontal trade-promo management tool with POS connectors bolted on the side.
Integration depth — 170+ FMCG implementations
Asseco Platform has been integrating retail and distribution data for FMCG producers across the region for two decades. Retailer onboarding is not a generic ERP project — it is a methodology refined across 170+ FMCG implementations and 160+ implementation specialists.
- →170+ FMCG implementations across CEE — producers, distributors, retailers
- →Two decades of POS-data work — CSV, XML, fixed-width, proprietary feeds
- →Same implementation team end-to-end — no handover to a third party mid-project
FMCG-only focus
Asseco Platform builds exclusively for FMCG. Every promotion mechanic supported, every retailer data feed integrated, every store dictionary structure modeled — all of it grounded in real FMCG operations, not in a horizontal feature catalog adapted to multiple industries.
- →6 promotion mechanics from real FMCG campaigns — not a generic TPM template
- →“Short EAN”, retailer-specific codes, branch hierarchies — common ground, not edge cases
Retailer onboarding as a service
Each retailer has its own ERP, its own data export logic and its own product coding conventions. Asseco does not assume a clean feed exists — we agree the technical interface with the retailer’s IT team, validate the data, and operate the feed end-to-end.
- →Direct engagement with the retailer’s IT team for the technical integration
- →SKU mapping and store dictionary built and maintained by Asseco
- →Daily reconciliation and data-quality flags operated as a managed service
Checkout-Based Settlement runs on two products. Trade Data Hub and Trade Terms & Settlement.
No additional Asseco products are needed for settlement on POS receipts. Trade Data Hub handles data acquisition; Trade Terms & Settlement hosts the promotion detector and refund formula.
Connects to each retailer’s POS feed, normalises the data, resolves SKU mapping and store hierarchy — the foundation under every settlement run.
Trade Terms & Settlement
Settlement engine hosting the promotion detector and the refund formula. The parent product under which Checkout-Based Promotional Settlement runs as a module.
Part of the Trade Promotion Settlement category. Sister modules for distributor sell-out and voucher redemption mechanics are in development.
Common questions about checkout-based settlement and POS data feeds.
Answers to the questions Sales Directors, Trade Marketing Managers and Finance Controllers ask most often before and during implementation.
What is Checkout-Based Promotional Settlement?
A module that automates trade promotion settlement between FMCG producers and retailers using POS receipt data. The producer no longer relies on the retailer’s own monthly declaration as the basis for refund — every transaction is verified at the till, the mechanic is identified per receipt, and the refund report is built on transactional source data.
How does it differ from distributor-based settlement?
This module reads POS receipt data directly from retailers — the retail sell-out layer. For promotions executed through distributors (the distributor sell-out layer), a separate sister module is required: Distributor-Based Promotional Settlement. Talk to us if that is your scenario.
Which retailers does it work with today?
Active integrations are in place across the Polish FMCG market today, with expansion planned across CEE. New retailers are onboarded individually — typical onboarding takes up to 12 weeks end-to-end, with the retailer’s IT preparation usually the longest step.
What about GDPR and personal data on receipts?
Receipt data is processed at transaction level, not at customer level. Loyalty-card identifiers and any personally identifiable information are excluded from the settlement feed. Data processing is governed by the producer–retailer data sharing agreement, and the system runs on infrastructure certified to ISO/IEC 27001:2022.
What happens if a retailer sends inconsistent data?
Trade Data Hub includes data-quality checks, deduplication and reconciliation routines on every daily feed. Inconsistencies are flagged automatically and routed back to the retailer for correction. Settlement reports include data-quality metadata so finance teams know which numbers are settled and which are pending.
Can it handle multiple promotions running in parallel?
Yes. Each transaction is verified independently against every active promotion. There is no limit on concurrent promotions — producers running campaigns across multiple retailers in parallel settle them in a single cycle, with no manual split between mechanics or retailers.
What promotion mechanics does it support?
Six mechanics are supported out-of-the-box: price promotions, multi-buy and package mechanics, value thresholds, seasonal time and store windows, bundle gratis (e.g. 4+2), and voucher-redemption equivalents. The list of supported mechanics is extended as new promotion types appear in client portfolios.
How does it integrate with our ERP and finance system?
Settlement reports export as XLSX, PDF or push directly through API to the producer’s ERP. The producer approves the report and routes it to finance through the existing accounts-payable workflow. Trade Terms & Settlement integrates with major ERPs in use across FMCG.
Move trade promotion settlement from a quarterly negotiation to a daily, audit-grade process.
Book a conversation with an Asseco Platform specialist. We will walk you through a real receipt-level settlement, talk through the retailer onboarding methodology, and map your trade promo programme to the detector capabilities.
