Smart Financial Review Formula
This document is the implementation reference for the Home > Smart Financial Review feature in the Kesles Merchant app.
Active implementation references:
smart_financial_review_form_page.dartsmart_financial_review_models.dartsmart_financial_review_result_page.dartsmart_financial_advanced_analysis_page.dartsmart_financial_growth_simulation_page.dart
Feature Purpose
Smart Financial Review is not a final net-profit calculator. The feature is used to:
- read the daily transaction scale of a business
- benchmark the business position against similar businesses
- give a quick health signal of the business
- give an early growth simulation
- flag inputs that are too extreme so they can be re-validated
Input
The feature currently uses these inputs:
Transactions per dayAverage transaction amountBusiness scaleBusiness categoryBusiness typeBusiness readiness checklist
Master data status notes:
Business Scale(Micro,Small,Medium) is already recorded as master data indb_referenceBusiness Scaleis now an active input in theSmart Financial Reviewpage- the active implementation currently uses
Business Scale,Business Category, andBusiness Typeas the primary benchmark input
Current readiness checklist:
- has organised transaction recording
- already accepts digital payments
- revenue is relatively stable
- has regular customers
- has tracked business cash flow
Source of Business Categories
The current business catalog is derived from the UMKM sectors in the Bank Indonesia document Profil Bisnis UMKM, then filtered to only the business types that realistically use a QRIS Plus device at a cashier, payment desk, or counter.
Master references currently prepared in db_reference:
ref_business_scaleref_business_categoryref_business_type
Business Scale
Currently active options:
MicroSmallMedium
The scale is used to adjust the base benchmark from Business Type.
Business scale guidance used in the current UI copy:
Micro- business capital: up to
Rp1,000,000,000 - monthly revenue: up to about
Rp166,666,667 - employee count:
1 - 4
- business capital: up to
Small- business capital:
Rp1,000,000,001 - Rp5,000,000,000 - monthly revenue: about
Rp166,666,668 - Rp1,250,000,000 - employee count:
5 - 19
- business capital:
Medium- business capital:
Rp5,000,000,001 - Rp10,000,000,000 - monthly revenue: about
Rp1,250,000,001 - Rp4,166,666,667 - employee count:
20 - 99
- business capital:
Notes:
- this capital, monthly revenue, and employee count guidance is used as business context and UI helper text
- the Smart Financial benchmark is still computed from the combination of
Business Scale + Business Category + Business Type - business capital figures follow
PP No. 7/2021criteria - monthly revenue is derived from the official
annual sales resultthresholds, then rounded to the nearest rupiah - employee count follows the BPS
Sensus Ekonomi 2016classification: micro1-4, small5-19, medium20-99 - the article UMKM Naik Kelas: Strategi, Tantangan, dan Solusi Digital yang Nyata is used only as narrative context, not as the primary cutoff numbers
BI sectors used as the basis:
TradeManufacturingServices
Important notes:
- the BI document is the sectoral reference
- the selection of business types in the app is the result of
Kesles Merchantproduct filtering - sectors such as agriculture, plantation, livestock, and fisheries are not included in this version because they do not always fit the QRIS Plus device usage pattern at a direct payment point
Categories and Benchmarks
Each Business type has its own benchmark:
daily transaction benchmarkticket size benchmarkbase operational cost rate
1. Trade Category
-
Grocery / Essentials Store- transaction benchmark:
150 - ticket size benchmark:
Rp 32,000 - base cost rate:
13%
- transaction benchmark:
-
Minimarket / Convenience Store- transaction benchmark:
190 - ticket size benchmark:
Rp 43,000 - base cost rate:
12%
- transaction benchmark:
-
Clothing & Accessories Store- transaction benchmark:
60 - ticket size benchmark:
Rp 175,000 - base cost rate:
15%
- transaction benchmark:
-
Pharmacy / Drug Store- transaction benchmark:
80 - ticket size benchmark:
Rp 95,000 - base cost rate:
14%
- transaction benchmark:
-
Cosmetics & Personal Care Store- transaction benchmark:
55 - ticket size benchmark:
Rp 135,000 - base cost rate:
15%
- transaction benchmark:
-
Electronics & Gadget Accessories Store- transaction benchmark:
22 - ticket size benchmark:
Rp 850,000 - base cost rate:
11%
- transaction benchmark:
-
Bookstore / Stationery / Photocopy- transaction benchmark:
70 - ticket size benchmark:
Rp 48,000 - base cost rate:
14%
- transaction benchmark:
2. Manufacturing Category
-
Coffee Shop- transaction benchmark:
110 - ticket size benchmark:
Rp 38,000 - base cost rate:
24%
- transaction benchmark:
-
Restaurant / Eatery- transaction benchmark:
145 - ticket size benchmark:
Rp 52,000 - base cost rate:
26%
- transaction benchmark:
-
Bakery- transaction benchmark:
95 - ticket size benchmark:
Rp 47,000 - base cost rate:
23%
- transaction benchmark:
-
Modern Drinks / Juice / Tea- transaction benchmark:
140 - ticket size benchmark:
Rp 28,000 - base cost rate:
24%
- transaction benchmark:
-
Snack Stall / Street Food- transaction benchmark:
130 - ticket size benchmark:
Rp 23,000 - base cost rate:
27%
- transaction benchmark:
-
Cake Shop / Dessert- transaction benchmark:
68 - ticket size benchmark:
Rp 92,000 - base cost rate:
23%
- transaction benchmark:
-
Catering / Daily Orders- transaction benchmark:
20 - ticket size benchmark:
Rp 430,000 - base cost rate:
20%
- transaction benchmark:
3. Services Category
-
Laundry by Weight- transaction benchmark:
48 - ticket size benchmark:
Rp 32,000 - base cost rate:
16%
- transaction benchmark:
-
Salon / Barbershop- transaction benchmark:
38 - ticket size benchmark:
Rp 78,000 - base cost rate:
17%
- transaction benchmark:
-
Motorbike / Car Workshop- transaction benchmark:
26 - ticket size benchmark:
Rp 185,000 - base cost rate:
18%
- transaction benchmark:
-
Motorbike / Car Wash- transaction benchmark:
44 - ticket size benchmark:
Rp 56,000 - base cost rate:
16%
- transaction benchmark:
-
Shipping / Parcel Agent- transaction benchmark:
72 - ticket size benchmark:
Rp 30,000 - base cost rate:
15%
- transaction benchmark:
-
Phone Credit Counter / PPOB- transaction benchmark:
88 - ticket size benchmark:
Rp 27,000 - base cost rate:
12%
- transaction benchmark:
-
Gadget / Electronics Repair- transaction benchmark:
18 - ticket size benchmark:
Rp 245,000 - base cost rate:
17%
- transaction benchmark:
-
Photo Studio / Printing- transaction benchmark:
24 - ticket size benchmark:
Rp 115,000 - base cost rate:
15%
- transaction benchmark:
Main Formulas
1. Benchmark after business scale adjustment
Current implementation:
benchmark_transactions = base_benchmark_transactions x scale_transaction_factor
benchmark_ticket_size = base_benchmark_ticket_size x scale_ticket_size_factor
Active scale factors:
-
Microtransaction_factor = 0.60ticket_size_factor = 0.78operational_cost_rate_adjustment = +2.0%
-
Smalltransaction_factor = 1.00ticket_size_factor = 1.00operational_cost_rate_adjustment = 0%
-
Mediumtransaction_factor = 1.85ticket_size_factor = 1.28operational_cost_rate_adjustment = -1.5%
2. Daily revenue
daily_revenue = daily_transactions x average_transaction_amount
3. Business readiness ratio
readiness_ratio = checked_checklist_count / total_checklist_count
Notes:
- if
total_checklist_count <= 0, the result is forced to0
4. Daily revenue benchmark
benchmark_daily_revenue = benchmark_transactions x benchmark_ticket_size
5. Ratios against benchmark
volume_ratio = daily_transactions / benchmark_transactions
ticket_size_ratio = average_transaction_amount / benchmark_ticket_size
daily_revenue_ratio = daily_revenue / benchmark_daily_revenue
6. Operational cost estimate
Current implementation:
operational_cost_rate =
base_operational_cost_rate
+ scale_operational_cost_rate_adjustment
- (readiness_ratio x 0.05)
+ scaled_bonus(volume_ratio)
+ scaled_bonus(ticket_size_ratio)
The final result is then bounded:
operational_cost_rate = clamp(10%, 32%)
Business meaning:
- the more operationally ready, the relatively more efficient the cost can be
- the higher the transaction scale and ticket size, the more the operational cost may also rise
7. Nominal operational cost
operational_cost = round(daily_revenue x operational_cost_rate)
8. Estimated net received
estimated_net_revenue = max(0, daily_revenue - operational_cost)
Score Formulas
1. Volume score normalisation
normalized_volume_score = normalized_score_from_ratio(volume_ratio)
2. Ticket size score normalisation
normalized_ticket_score = normalized_score_from_ratio(ticket_size_ratio)
3. Revenue score normalisation
normalized_revenue_score = normalized_score_from_ratio(daily_revenue_ratio)
Current normalisation function:
- if ratio
<= 0, result0 - if ratio
0 - 1, result follows the ratio - if ratio
> 1, result is given a bounded logarithmic bonus so the score keeps rising but does not explode
Anomaly Penalty
This feature applies a penalty so that extreme inputs are not always treated as very healthy.
High anomaly
Enters high anomaly if any of the following is true:
ticket_size_ratio > 8volume_ratio > 10daily_revenue_ratio > 80
Extreme anomaly
Enters extreme anomaly if any of the following is true:
ticket_size_ratio > 25volume_ratio > 40daily_revenue_ratio > 400
Penalty formula
The penalty is built from three components:
ticket_penalty
volume_penalty
revenue_penalty
After summation:
anomaly_penalty = clamp(0, 0.80)
Overall Score
Current implementation:
overall_score =
(normalized_volume_score x 0.30)
+ (normalized_ticket_score x 0.25)
+ (normalized_revenue_score x 0.25)
+ (readiness_ratio x 0.20)
- anomaly_penalty
The result is then bounded:
overall_score = clamp(0, 1.25)
Status Criteria
Status evaluation order:
- if
hasExtremeAnomaly- label:
Data Needs Validation
- label:
- if
hasHighAnomaly- label:
Scale Above Benchmark
- label:
- if
overall_score >= 1.05- label:
Very Strong
- label:
- if
overall_score >= 0.95- label:
Healthy & Stable
- label:
- if
overall_score >= 0.75- label:
Fairly Stable
- label:
- if
overall_score >= 0.55- label:
Ready to Grow
- label:
- otherwise
- label:
Needs Attention
- label:
Growth Potential Simulation
1. Suggested additional transactions
If extreme anomaly:
suggested_extra_transactions =
max(10, min(1% x daily_transactions, 100))
If high anomaly:
suggested_extra_transactions =
max(10, min(3% x daily_transactions, 150))
If benchmark not yet reached:
suggested_extra_transactions =
benchmark_transactions - daily_transactions
If already above benchmark:
suggested_extra_transactions =
max(5, min(12% x daily_transactions, 75))
2. Revenue potential
potential_daily_revenue =
(daily_transactions + suggested_extra_transactions) x average_transaction_amount
3. Net received potential
potential_net_revenue =
max(0, potential_daily_revenue - round(potential_daily_revenue x operational_cost_rate))
4. Growth percentage
growth_potential_percentage =
((potential_net_revenue - estimated_net_revenue) / estimated_net_revenue) x 100
Notes:
- if
estimated_net_revenue <= 0, the growth percentage is forced to0
Calculation Examples
Example 1
Input:
- category:
Trade - business type:
Grocery / Essentials Store - transactions per day:
100 - average transaction:
Rp 100,000 - checklist met:
4/5
Benchmark:
- transaction benchmark:
150 - ticket size benchmark:
Rp 32,000 - base cost rate:
13%
Basic results:
daily_revenue = 100 x 100.000 = 10.000.000
readiness_ratio = 4 / 5 = 0,80
volume_ratio = 100 / 150 = 0,67
ticket_size_ratio = 100.000 / 32.000 = 3,13
benchmark_daily_revenue = 150 x 32.000 = 4.800.000
daily_revenue_ratio = 10.000.000 / 4.800.000 = 2,08
Interpretation:
- daily revenue is above the grocery store benchmark
- ticket size is also far above the grocery store benchmark
- not yet automatically considered an anomaly because still below the
high anomalythreshold
Example 2
Input:
- category:
Trade - business type:
Grocery / Essentials Store - transactions per day:
1,000 - average transaction:
Rp 1,000,000
Interpretation:
volume_ratioandticket_size_ratiojump very high- result enters at minimum
Scale Above Benchmark - if the ratio crosses extreme thresholds, the result becomes
Data Needs Validation
Example 3
Input:
- category:
Trade - business type:
Grocery / Essentials Store - transactions per day:
100,000 - average transaction:
Rp 100,000,000
Interpretation:
- volume, ticket size, and revenue will far exceed validation thresholds
- the result is forced to
Data Needs Validation - the goal of this logic is to prevent the score from looking too healthy when the input is likely to have an extra zero or unit error
Model Design Principles
The current model is intentionally:
- more sensitive to differences across business types
- not equating a grocery store with a coffee shop or a workshop
- still leaves room for businesses that genuinely grow above benchmark
- but applies a penalty for inputs that are too extreme
As a result:
100 transactions x Rp 100,000100 transactions x Rp 1,000,0001,000 transactions x Rp 100,000100,000 transactions x Rp 1,000,000
will not fall into the same status.
Limitations of the Current Version
This model does not yet include:
- MDR
- tax
- employee salary
- rent
- utilities
- detailed raw material cost
- discount and promo
- returns
- daily device service fee
- seasonal cost
So:
estimated_net_revenueis an early operational estimate- not the final accounting net profit
Recommended Next Enhancements
If the feature is to become more precise, the next version should add:
MDRrent / utilities costsalaryraw material costdiscountreturnsoperational days per monthdevice / service cost
This way, the analysis output can grow into:
- daily revenue
- daily operating profit
- daily net profit
- monthly projection
- cost efficiency against a similar-business benchmark