Skip to main content

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.dart
  • smart_financial_review_models.dart
  • smart_financial_review_result_page.dart
  • smart_financial_advanced_analysis_page.dart
  • smart_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 day
  • Average transaction amount
  • Business scale
  • Business category
  • Business type
  • Business readiness checklist

Master data status notes:

  • Business Scale (Micro, Small, Medium) is already recorded as master data in db_reference
  • Business Scale is now an active input in the Smart Financial Review page
  • the active implementation currently uses Business Scale, Business Category, and Business Type as 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_scale
  • ref_business_category
  • ref_business_type

Business Scale

Currently active options:

  • Micro
  • Small
  • Medium

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
  • 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
  • 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

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/2021 criteria
  • monthly revenue is derived from the official annual sales result thresholds, then rounded to the nearest rupiah
  • employee count follows the BPS Sensus Ekonomi 2016 classification: micro 1-4, small 5-19, medium 20-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:

  • Trade
  • Manufacturing
  • Services

Important notes:

  • the BI document is the sectoral reference
  • the selection of business types in the app is the result of Kesles Merchant product 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 benchmark
  • ticket size benchmark
  • base operational cost rate

1. Trade Category

  • Grocery / Essentials Store

    • transaction benchmark: 150
    • ticket size benchmark: Rp 32,000
    • base cost rate: 13%
  • Minimarket / Convenience Store

    • transaction benchmark: 190
    • ticket size benchmark: Rp 43,000
    • base cost rate: 12%
  • Clothing & Accessories Store

    • transaction benchmark: 60
    • ticket size benchmark: Rp 175,000
    • base cost rate: 15%
  • Pharmacy / Drug Store

    • transaction benchmark: 80
    • ticket size benchmark: Rp 95,000
    • base cost rate: 14%
  • Cosmetics & Personal Care Store

    • transaction benchmark: 55
    • ticket size benchmark: Rp 135,000
    • base cost rate: 15%
  • Electronics & Gadget Accessories Store

    • transaction benchmark: 22
    • ticket size benchmark: Rp 850,000
    • base cost rate: 11%
  • Bookstore / Stationery / Photocopy

    • transaction benchmark: 70
    • ticket size benchmark: Rp 48,000
    • base cost rate: 14%

2. Manufacturing Category

  • Coffee Shop

    • transaction benchmark: 110
    • ticket size benchmark: Rp 38,000
    • base cost rate: 24%
  • Restaurant / Eatery

    • transaction benchmark: 145
    • ticket size benchmark: Rp 52,000
    • base cost rate: 26%
  • Bakery

    • transaction benchmark: 95
    • ticket size benchmark: Rp 47,000
    • base cost rate: 23%
  • Modern Drinks / Juice / Tea

    • transaction benchmark: 140
    • ticket size benchmark: Rp 28,000
    • base cost rate: 24%
  • Snack Stall / Street Food

    • transaction benchmark: 130
    • ticket size benchmark: Rp 23,000
    • base cost rate: 27%
  • Cake Shop / Dessert

    • transaction benchmark: 68
    • ticket size benchmark: Rp 92,000
    • base cost rate: 23%
  • Catering / Daily Orders

    • transaction benchmark: 20
    • ticket size benchmark: Rp 430,000
    • base cost rate: 20%

3. Services Category

  • Laundry by Weight

    • transaction benchmark: 48
    • ticket size benchmark: Rp 32,000
    • base cost rate: 16%
  • Salon / Barbershop

    • transaction benchmark: 38
    • ticket size benchmark: Rp 78,000
    • base cost rate: 17%
  • Motorbike / Car Workshop

    • transaction benchmark: 26
    • ticket size benchmark: Rp 185,000
    • base cost rate: 18%
  • Motorbike / Car Wash

    • transaction benchmark: 44
    • ticket size benchmark: Rp 56,000
    • base cost rate: 16%
  • Shipping / Parcel Agent

    • transaction benchmark: 72
    • ticket size benchmark: Rp 30,000
    • base cost rate: 15%
  • Phone Credit Counter / PPOB

    • transaction benchmark: 88
    • ticket size benchmark: Rp 27,000
    • base cost rate: 12%
  • Gadget / Electronics Repair

    • transaction benchmark: 18
    • ticket size benchmark: Rp 245,000
    • base cost rate: 17%
  • Photo Studio / Printing

    • transaction benchmark: 24
    • ticket size benchmark: Rp 115,000
    • base cost rate: 15%

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:

  • Micro

    • transaction_factor = 0.60
    • ticket_size_factor = 0.78
    • operational_cost_rate_adjustment = +2.0%
  • Small

    • transaction_factor = 1.00
    • ticket_size_factor = 1.00
    • operational_cost_rate_adjustment = 0%
  • Medium

    • transaction_factor = 1.85
    • ticket_size_factor = 1.28
    • operational_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 to 0

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, result 0
  • 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 > 8
  • volume_ratio > 10
  • daily_revenue_ratio > 80

Extreme anomaly

Enters extreme anomaly if any of the following is true:

  • ticket_size_ratio > 25
  • volume_ratio > 40
  • daily_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
  • if hasHighAnomaly
    • label: Scale Above Benchmark
  • if overall_score >= 1.05
    • label: Very Strong
  • if overall_score >= 0.95
    • label: Healthy & Stable
  • if overall_score >= 0.75
    • label: Fairly Stable
  • if overall_score >= 0.55
    • label: Ready to Grow
  • otherwise
    • label: Needs Attention

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 to 0

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 anomaly threshold

Example 2

Input:

  • category: Trade
  • business type: Grocery / Essentials Store
  • transactions per day: 1,000
  • average transaction: Rp 1,000,000

Interpretation:

  • volume_ratio and ticket_size_ratio jump 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,000
  • 100 transactions x Rp 1,000,000
  • 1,000 transactions x Rp 100,000
  • 100,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_revenue is an early operational estimate
  • not the final accounting net profit

If the feature is to become more precise, the next version should add:

  • MDR
  • rent / utilities cost
  • salary
  • raw material cost
  • discount
  • returns
  • operational days per month
  • device / 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