Price Lists and Discount Authority Across Sales Channels in a Türkiye Subsidiary

A regional sales manager at a Türkiye subsidiary agrees a discount on the phone, then adjusts the invoice price by hand when the order is entered. A colleague sells the same item to a similar customer at a different discount. Both believe their decision was reasonable, because the only reference either of them has is personal experience. At quarter end, the finance team reviewing margin cannot tell which discounts were approved and which were improvised.

The parent company sees the result as an unexplained gap between list price and realised price. This guide describes how price lists, discount tiers and approval limits are structured in an ERP so that the gap has an explanation.

Why is a single price list not enough?

Most subsidiaries start with one list price and add manual discounts as the customer base grows. The weakness is that a manual discount is recorded nowhere except on the invoice it was applied to. The next order from the same customer has no memory of it. The salesperson either repeats the discount from memory or falls back to the list price, and the customer notices either way.

The usual fix is several lists, each tied to a customer type:

• A dealer list, typically the lowest, tied to volume
• A retail or end-customer list
• An export list, held in a foreign currency
• An online or marketplace list that already accounts for platform commission

Once a customer card points to a list, the system fetches that price when an order is entered. The salesperson no longer decides which price applies. That decision was made when the customer was set up.

How should discount tiers be defined?

A discount tier ties the percentage to something measurable, so it can be checked later. Common drivers are order quantity, annual purchase volume, product group and payment term. A customer who pays upfront and a customer who takes long payment terms should not receive the same tier, because the second one costs you financing as well.

A practical test of a tier structure is whether a new salesperson could apply it correctly on the first day without asking anyone. If the answer depends on knowing the history of the account, the rule is still in someone's head and not in the system.

Who is allowed to go beyond the tier?

No tier structure covers every negotiation, so the question becomes who can grant an exception and up to what point. Approval limits are usually layered by role:

Role	Typical authority
Salesperson	Applies the tier only, no exceptions
Sales manager	Exceptions up to a defined percentage
Finance or general manager	Anything beyond that, with a written reason

The percentages are your own decision and differ by business. What matters is that the system enforces them. An order that exceeds the limit is held until the right person approves it, and the approval, the approver and the reason stay on the order record.

What goes wrong when pricing is edited by hand on the invoice?

Three things. The order and the invoice stop matching, so the customer receives a price nobody confirmed in writing. The discount cannot be reported, because it was never captured in a field. And the audit trail breaks: a parent company reviewer asking why a customer's average price fell has nothing to trace.

Moving the discount to the order line, as a separate field from the list price, removes all three. The invoice is generated from the order and not retyped.

What can the parent company review once this is in place?

With list price, applied price and discount held as separate values, a few reports become routine:

• Average discount by customer, product group and salesperson
• Orders that required approval, who approved them and why
• Customers whose realised price has drifted from their assigned list
• Campaign prices and their start and end dates, so expired promotions are not still being honoured

None of this requires a special project. It is a by-product of capturing the discount in the right place at the moment of entry.

How does Birasyo structure this?

In Birasyo's sales module, price lists can be defined by customer, category and period, and tiered discounts and campaign rules are set up alongside them. Quotes and orders carry a version history and an approval flow, so an exception follows the approval route you define. For a view across customers, the reports module provides a drag-and-drop report designer that does not require SQL, and reports can be scheduled to arrive by email.

If you would like to see how your current pricing rules would map onto this structure, you can request a demo and bring a sample of your price list.

Summary

• A single list price plus manual discounts leaves no record of why a customer pays what they pay.
• Separate price lists for dealers, retail, export and online channels move the pricing decision to customer setup.
• Discount tiers should rest on measurable drivers such as quantity, annual volume, product group and payment term.
• Approval limits by role, enforced by the system, keep exceptions visible and explained.
• Keeping list price, applied price and discount as separate fields gives the parent company reports it can rely on.

Sources and note

This guide describes a process design and does not rely on statutory figures. Pricing and discount policy should be set with your finance team and checked with your financial advisor where tax treatment of discounts or invoices is concerned. Please confirm with your financial advisor before changing invoicing practice.