Sales commissions in your ERP: how to leave Excel and stop arguing every month

· 6 min read · SilverData team

Month-end in many small trading companies looks the same everywhere: the finance director shuts the door for three days, copies the sales register from the ERP into Excel, manually subtracts returns and corrections, and then explains to sales reps why their commission "came out different than last month". This isn't an accounting problem. It's a systems problem — and it's solvable.

Commissions in Excel are a classic example of a process that "just works", as long as the company is small. Three reps, a simple scheme: percentage of revenue, paid by the 10th of the following month. It all fits in one head and one spreadsheet. But add a fourth rep, switch the scheme to "percentage of margin", add a bonus for a new client and returns that show up two months late — and the spreadsheet takes on a life of its own. Formulas break, someone forgets to update the quarterly bonus, a rep gets paid 400 zloty less than expected and marches into the owner's office. Month after month.

Commission isn't just a cost. It's the tool a company uses to steer sales behaviour. If a rep doesn't understand how their commission was calculated, they don't trust the system — and they stop responding to what the company was trying to signal.

What "commissions in the system" actually means

For an SME this isn't about a dedicated SPM module costing hundreds of thousands. It's about something simpler: one place where the commission rule meets the real sales data from the ERP — without any manual re-typing.

In practice that means three things. First, commission rules live in one place, in a form that both the finance director and the sales rep can read (not in the owner's head). Second, the commission engine pulls invoices, corrections and payments directly from the ERP — not from an export that someone made three days ago. Third, the sales rep sees their running commission more often than once a month, ideally daily.

Most popular ERPs in Poland — Comarch Optima, enova365, Subiekt GT, Microsoft Dynamics — have some kind of commission modules or reports. They differ in rule flexibility. Comarch Optima and enova365 let you build fairly complex schemes natively; Subiekt is more limited and often gets an external rule sheet bolted onto it. There is no single right answer to "what should I calculate this in" — there is only a right answer to "how do I get out of Excel".

The foundation — simple rules

The single biggest mistake we see when moving commissions into a system is trying to port over the entire historical tangle one-to-one. The company has accumulated ten different schemes over the years, each sales rep has their own exception, quarterly bonuses depend on three conditions at once. Someone tries to code all of that in, and a month later they're back in Excel because "the system can't handle it".

Before you feed rules into the ERP, tidy them up. It's a painful, political conversation — but a one-time one.

A handful of clear rules will calculate fine in an ERP. A dozen conditions, exceptions and informal side deals won't calculate anywhere.

A real example

An 18-person electrical wholesaler near Poznań, 5 sales reps. Commission depends on margin realised on the invoice (not on revenue — the owner got burned once when reps started selling at cost to hit their targets). On top of that: commission accrues only after the customer pays the invoice, and any credit note claws it back proportionally.

Until January 2026 it looked like this: 3–4 days after month-end, the finance director exported the sales register from Comarch Optima into Excel, manually added payments (from a separate bank report), subtracted credit notes from the current and prior months, recalculated margin against purchase costs and multiplied by each rep's individual rate. Month-end closing took 2–3 full working days. Every second month one of the reps disputed the result, because "I get a different number in my own Excel".

The rollout: configuring the commission module in Comarch Optima with rules based on margin and invoice payment status. One-off cost: about 8,000 zloty (analysis + configuration + testing on data from 3 closed months). Plus a simple intranet report where each rep sees their running commission daily, broken down by invoice.

After three months: month-end takes 20–30 minutes (a control, not a recalculation). Arguments about commissions have practically disappeared — if something looks off, the rep can see for themselves in the report that invoice X hasn't been paid, so there's no commission on it yet. An unexpected bonus: two reps started actively chasing their own customers' payments, because they can see their commission literally depends on it. Overdue receivables dropped.

This isn't a story about "AI transforming the business". It's a story about "we moved the rules out of someone's head into the system".

When it's not worth it

Not every company needs commission automation. If you have two reps, a simple percentage of revenue and a stable scheme for years — Excel is fine. The rollout cost would eat any savings for the next two years.

It's worth thinking about leaving Excel in a few situations:

What to watch for during rollout

A few things where we've seen the most trouble:

What next

Commissions in the ERP is one of those projects that isn't sexy, won't wow anyone at a conference and won't show up in a Gartner report. But it pays back fast — because it saves days of finance work, ends the monthly arguments and actually changes sales behaviour.

If month-end in your company looks like the wholesaler above — instead of adding one more exception to Excel, check what it would really cost to leave Excel behind. The first call is free and takes half an hour.

A commission a sales rep doesn't understand doesn't steer sales. It steers an argument with accounting.

← Back to blog