mirror of
https://github.com/Karaka-Management/Organization-Guide.git
synced 2026-01-11 04:48:42 +00:00
11 KiB
11 KiB
Sales Risk Control Matrix
| No. | R | Category | Risk Event | L | C | F | Cause | Mitigation Type | Mitigation Strategy | L* | C* | Changes | Comments | ES | EY | Evidences |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Sales | Operational Risk (Sales) | Invalid offer | 1 | 1 | Many times a day | Preventing (System) | Use default offers. | 1 | 1 | yes | yes | ||||
| 2 | Sales | Operational Risk (Sales) | No flexibility in case of none-standard customer requests. | 1 | 1 | Many times a day | Preventing (Manual) | Custom offers for customers. | 1 | 1 | yes | yes | ||||
| 3 | Head of Sales / Head of Finance | Operational Risk (Sales) | Prices too low / discounts too large | 1 | 5 | Many times a day | Preventing (System & Manual) | Default prices and standard discounts are stored in the IT system responsible for the offer generation. | 1 | 1 | yes | yes | ||||
| 4 | CEO | Operational Risk (Sales) | Prices too low / discounts too large | 1 | 5 | Many times a day | Preventing (System & Manual) | Deviations from the pricing policy require additional electronic approval in the system by the head of sales or head of finance. Without this electronic approval the offer cannot get created. | 1 | 1 | yes | yes | ||||
| 5 | Head of Sales / Head of finance | Operational Risk (Sales) | Default prices are too low / default discounts are too large | 1 | 5 | Many times a day | Preventing (System & Manual) | Changes to default prices and default discounts can only be entered into the IT system by the head of sales or head of finance. | 1 | 1 | yes | yes | ||||
| 6 | Sales | Operational Risk (Sales) | Changes to offers, order confirmations, offers etc. | 1 | 1 | Many times a day | Preventing (System) | Changes are only possible as long as they are not marked as delivered in the IT system. | 1 | 1 | yes | yes | ||||
| 7 | Sales | Operational Risk (Sales) | Other aspects of the offer are invalid (i.e. wrong customer, bad credit score of customer, ...) | 1 | 5 | Many times a day | Preventing (System) | The offer is none-binding and only becomes binding with the order confirmation where additional checks are performed. | 1 | 1 | yes | yes | ||||
| 8a | Sales | Operational Risk (Sales) | Invalid order from customer (e.g. changes to the offer) | 1 | 1 | Many times a day | Preventing (Manual) | The order from the customer must be checked by a sales clerk. | 1 | 1 | yes | yes | ||||
| 8b | Sales | Operational Risk (Sales) | Invalid order from customer (e.g. changes to the offer) | 1 | 1 | Many times a day | Preventing (System) | Online orders from the shop are automatically generated by the IT system according to the allowed prices and products etc. | 1 | 1 | yes | yes | ||||
| 9 | Sales | Operational Risk (Sales) | Invalid tax calculation | 1 | 1 | Many times a day | Preventing (System) | The IT system automatically calculates the taxes based on the item and customer settings. | 1 | 1 | yes | yes | ||||
| 10 | Sales | Operational Risk (Sales) | Invalid automatic tax calculation | 1 | 1 | Many times a day | Preventing (Manual) | An accountant can adjust the taxes if necessary. | 1 | 1 | This can be necessary for special cases such as chain transactions. | yes | yes | |||
| 11 | Head of sales | Operational Risk (Sales) | Changes between order confirmation and invoice. | 1 | 1 | Many times a day | Preventing (System & Manual) | Changes between order confirmation and invoice must be approved by the head of sales before the invoice can get created. | 1 | 1 | yes | yes | ||||
| 12 | Accounting | Operational Risk (Finance) | Invalid posting. | 1 | 1 | Many times a day | Preventing (System) | The IT system automatically generates the posting for invoices based on item and customer settings. | 1 | 1 | yes | yes | ||||
| 13 | Accounting | Operational Risk (Finance) | Unpaid invoice. | 1 | 1 | Every 2 Weeks | Revealing (System) | The IT system automatically generates reminders every 2 weeks. | 1 | 1 | yes | yes | ||||
| 14 | Accounting | Operational Risk (Finance) | Customer continues to receive products despite not paying invoices. | 1 | 1 | Every 2 Weeks | Preventing (System) | The IT system automatically locks the customer account preventing further customer orders. | 1 | 1 | yes | yes | ||||
| 15 | Accounting | Operational Risk (Finance) | Customers don't pay after reminder. | 1 | 1 | Every 2 Weeks | Revealing (Manual) | Invoices can get handed over to a lawyer for collection based on the decision of the head of finance. | 1 | 1 | yes | yes | ||||
| 16 | Accounting | Operational Risk (Finance) | Invalid payment matching. | 1 | 1 | Many times a day | Preventing (System) | The IT system generates suggestions for matching payments with customers/invoices. | 1 | 1 | yes | yes | ||||
| 17 | Accounting | Operational Risk (Finance) | Invalid payment suggestion matching. | 1 | 1 | Many times a day | Preventing (Manual) | The account can manually adjust the payment matching. | 1 | 1 | yes | yes | ||||
| 18 | Sales | Operational Risk (Purchase) | Missing customer information (e.g. important tax information) | 1 | 1 | Many times a day | Preventing (System) | The IT system requires mandatory information before invoices and order confirmations can be created for a customer. | 1 | 1 | yes | yes | ||||
| 19 | Sales | Operational Risk (Purchase) | Invalid customer information | 1 | 1 | Many times a day | Preventing (System) | The IT system performs automatic checks. | 1 | 1 | yes | yes | ||||
| 19a | Sales | Operational Risk (Sales) | Invalid customer data | 1 | 5 | Many times a day | Preventing (System) | Customer data gets compared with the information provided from credit rating agencies, company registration forms etc. | 1 | 1 | yes | yes | ||||
| 19b | Sales | Operational Risk (Sales) | Customer default | 1 | 5 | Many times a day | Preventing (System) | Only customers with a credit score of XXXX-Crefo / XXXX-Coface / XXXX-Schufa get approved during the order confirmation. | 1 | 1 | yes | yes | ||||
| 20 | Head of sales | Operational Risk (Purchase) | False positive customer errors. | 1 | 1 | Many times a day | Preventing (Manual) | Manual customer approval by head of sales | 1 | 1 | yes | yes | ||||
| 21 | Sales | Operational Risk (Purchase) | Critical changes to customer (e.g. sanctions) | 1 | 1 | Daily | Preventing (System) | The IT system automatically checks customers against sanction lists every day. | 1 | 1 | yes | yes |
Abbreviations
-
R: Responsible
-
L: Likelihood (1-5)
-
C: Consequence (1-5)
-
L*/C*: Likelihood and Consequence after mitigation
-
F: Frequency (many times a day, daily, weekly, monthly, annually)
-
ES: Effective
-
EY: Efficient
2022-01-01 - Version 1.0