Mẫu Google Sheets Tính Hoa Hồng Bán Hàng Theo Bậc Thang [2026]

Bậc thang hoa hồng khác gì với hoa hồng phẳng — và vì sao nhiều shop tính sai

Cách tính hoa hồng phổ biến nhất vẫn là nhân doanh số với một tỷ lệ cố định, kiểu 5% cho mọi đơn hàng. Cách này dễ làm nhưng có một lỗ hổng: nhân viên bán được 50 triệu hay 500 triệu trong tháng cũng chỉ nhận đúng một mức thưởng tương ứng theo tỷ lệ, không có động lực để đẩy doanh số vượt ngưỡng. Bậc thang (tiered commission) giải quyết việc này bằng cách chia doanh số thành các khoảng, mỗi khoảng ứng với một tỷ lệ hoa hồng khác nhau — càng bán nhiều, tỷ lệ hoa hồng cho phần vượt càng cao.

Vấn đề là công thức tính bậc thang trong Excel/Google Sheets phức tạp hơn hẳn một phép nhân đơn giản, và đây chính là chỗ nhiều bảng tính tự chế bị sai. Có hai kiểu tính bậc thang hoàn toàn khác nhau mà người làm bảng lương hay nhầm lẫn:

• Bậc thang lũy tiến (marginal/graduated): mỗi mức doanh số chỉ áp tỷ lệ tương ứng cho phần doanh số nằm trong khoảng đó, giống cách tính thuế thu nhập cá nhân.
• Bậc thang toàn phần (all-in tier): một khi đạt ngưỡng, TOÀN BỘ doanh số trong tháng được áp tỷ lệ cao nhất tương ứng, không chỉ phần vượt.

Hai cách này ra kết quả chênh nhau khá nhiều ở gần ngưỡng, và nếu công ty dùng sai loại so với chính sách đã công bố, nhân viên sẽ phát hiện ra ngay khi đối chiếu lương — mất niềm tin vào cả hệ thống thưởng.

Cấu trúc bảng dữ liệu gốc trước khi viết công thức

Trước khi đụng đến hàm nào, cần một sheet dữ liệu thô sạch sẽ. Một sai lầm thường gặp là nhồi luôn công thức hoa hồng vào sheet giao dịch bán hàng — khi cần đổi chính sách hoa hồng giữa kỳ (điều này xảy ra thường xuyên hơn bạn nghĩ), phải sửa hàng trăm dòng công thức thay vì một bảng cấu hình duy nhất.

Cấu trúc tối thiểu nên tách thành 3 sheet:

• Sheet "Giao dịch": Ngày bán, Mã NV, Tên NV, Mã đơn, Giá trị đơn hàng, Loại sản phẩm (nếu tỷ lệ khác nhau theo dòng sản phẩm)
• Sheet "Bậc thang": Mức tối thiểu, Mức tối đa, Tỷ lệ hoa hồng — mỗi dòng là một bậc
• Sheet "Tổng hợp": gộp doanh số theo NV theo tháng bằng SUMIFS, rồi mới áp công thức bậc thang

Ví dụ bảng bậc thang cho một team sale B2C:

Mức doanh số (VNĐ)	Tỷ lệ hoa hồng
0 – 50.000.000	3%
50.000.001 – 100.000.000	5%
100.000.001 – 200.000.000	7%
Trên 200.000.000	10%

Việc tách bảng bậc thang riêng ra một vùng cấu hình có ý nghĩa thực tế: cuối quý, sếp đổi chính sách thưởng, bạn chỉ cần sửa 4 dòng trong bảng này thay vì rà từng công thức trong sheet giao dịch.

Công thức tính bậc thang lũy tiến — dùng hàm gì và vì sao

Với kiểu lũy tiến, không thể chỉ dùng VLOOKUP đơn thuần vì nó chỉ trả về tỷ lệ của một bậc, không tự cộng dồn phần hoa hồng của các bậc thấp hơn. Cách làm chắc ăn nhất là dựng một công thức tính từng đoạn bằng hàm lồng IF, hoặc dùng SUMPRODUCT nếu bảng bậc thang dài. Giả sử doanh số nhân viên nằm ở ô B2, và bảng bậc thang ở D2:F5 (Mức tối thiểu, Mức tối đa, Tỷ lệ), công thức lũy tiến cho 4 bậc như ví dụ trên sẽ là:

=MAX(0,MIN(B2,50000000))*3%
+MAX(0,MIN(B2,100000000)-50000000)*5%
+MAX(0,MIN(B2,200000000)-100000000)*7%
+MAX(0,B2-200000000)*10%

Cấu trúc lặp MAX(0, MIN(doanh số, mức trần) - mức sàn) chính là phần "khối lượng doanh số nằm trong bậc này". Nhân viên bán 120 triệu sẽ được tính: 50 triệu đầu x 3%, 50 triệu tiếp theo x 5%, 20 triệu còn lại x 7% — tổng cộng 1.500.000 + 2.500.000 + 1.400.000 = 5.400.000đ, chứ không phải 120 triệu x 7% = 8.400.000đ như nhiều người tính nhầm bằng VLOOKUP một lần. Nếu bảng bậc thang có nhiều hơn 4-5 mức và công thức lồng nhau trở nên khó đọc, có thể chuyển sang SUMPRODUCT tham chiếu trực tiếp vào bảng cấu hình, tự động mở rộng khi thêm bậc mới mà không phải sửa công thức thủ công. Đây là lựa chọn tốt hơn về lâu dài nếu công ty hay điều chỉnh số bậc.

Công thức tính bậc thang toàn phần — đơn giản hơn nhưng dễ gây tranh cãi

Nếu chính sách công ty là kiểu "đạt ngưỡng nào thì áp tỷ lệ đó cho toàn bộ doanh số", công thức lại đơn giản hơn hẳn — chỉ cần một VLOOKUP dạng gần đúng (approximate match):

=B2*VLOOKUP(B2,$D$2:$F$5,3,TRUE)

Với điều kiện cột Mức tối thiểu trong bảng bậc thang phải được sắp xếp tăng dần, VLOOKUP với tham số TRUE sẽ tìm mức bậc lớn nhất mà vẫn nhỏ hơn hoặc bằng doanh số, rồi lấy tỷ lệ tương ứng nhân với toàn bộ doanh số. Cách này dễ viết công thức nhưng tạo ra hiệu ứng "cliff" — chênh 1 đồng ở ngay ngưỡng có thể làm hoa hồng nhảy vọt bất hợp lý. Ví dụ doanh số 99.999.999đ hưởng 3% (2.999.999đ), nhưng chỉ cần thêm 2đ để chạm mốc 100 triệu là nhảy lên 5% cho toàn bộ (5.000.000đ) — chênh 2 triệu chỉ vì 2 đồng doanh số. Nhân viên tinh ý sẽ tìm cách "câu" đơn hàng cuối tháng để né/vượt ngưỡng, gây méo mó dữ liệu bán hàng thật. Nếu công ty chọn kiểu này, nên cân nhắc thêm cơ chế làm mượt ở vùng sát ngưỡng, hoặc đơn giản là chuyển sang lũy tiến — bản chất công bằng hơn và ít bị lách luật hơn.

Xử lý các tình huống thực tế: nhiều dòng sản phẩm, target theo tháng, và trả chậm

Bảng bậc thang lý thuyết ở trên giả định một tỷ lệ áp dụng chung, nhưng thực tế bán hàng phức tạp hơn nhiều. Ba tình huống hay gặp:

Nhiều dòng sản phẩm với bậc thang khác nhau

Nếu công ty bán cả sản phẩm chính và phụ kiện với chính sách hoa hồng riêng, không nên gộp doanh số rồi áp một bảng bậc thang chung. Cách xử lý đúng là tách SUMIFS theo Loại sản phẩm trước, tính bậc thang riêng cho từng loại, rồi mới cộng tổng hoa hồng ở bước cuối. Nhồi tất cả vào một công thức khổng lồ sẽ khiến việc debug khi sai số gần như bất khả thi.

Target theo tháng nhưng chốt doanh số theo ngày ký hợp đồng

Đây là lỗi hay bị bỏ sót: nếu hợp đồng ký ngày 28/2 nhưng khách thanh toán ngày 3/3, doanh số này tính vào tháng nào để lên bậc? Cần thống nhất rõ mốc tính (ngày ký, ngày thu tiền, hay ngày giao hàng) và dùng đúng cột ngày đó trong công thức SUMIFS gộp theo tháng — nếu bạn cần tính khoảng cách giữa ngày ký và ngày thu tiền để đối soát công nợ, có thể tham khảo cách tính số ngày giữa hai mốc thời gian trong Google Sheets.

Hoa hồng giữ lại chờ đối soát (hold-back)

Nhiều công ty giữ lại 20-30% hoa hồng của đơn hàng lớn trong 1-2 tháng để tránh trường hợp khách hủy/trả hàng sau khi đã trả hoa hồng đủ. Nếu áp dụng cơ chế này, nên thêm một cột "Trạng thái đơn hàng" và chỉ SUMIFS những đơn có trạng thái "Đã xác nhận" vào bậc thang tính lương tháng đó, phần còn giữ lại tính riêng ở cột kế bên để theo dõi.

Với các ngành có cơ chế hoa hồng theo ca làm hoặc theo dịch vụ thực hiện (không hẳn theo doanh số bán hàng thuần túy), cách tính sẽ khác — có thể tham khảo thêm ở bài tính hoa hồng kỹ thuật viên spa bằng Google Sheets để thấy cách áp dụng bậc thang theo số lượng dịch vụ thay vì doanh số tiền.

Dựng dashboard theo dõi tiến độ bậc thang theo thời gian thực

Bảng tính chỉ đúng công thức thôi chưa đủ — nhân viên sale cần nhìn thấy mình đang cách bậc tiếp theo bao xa để có động lực đẩy nốt trong những ngày cuối tháng. Một dashboard tối thiểu nên có:

• Doanh số lũy kế tháng hiện tại (SUMIFS theo NV và tháng)
• Bậc hiện tại đang đứng và tỷ lệ hoa hồng tương ứng (dùng VLOOKUP/XLOOKUP tra cứu)
• Số tiền còn thiếu để lên bậc kế tiếp: =Mức_trần_bậc_hiện_tại - Doanh_số_lũy_kế
• Thanh tiến độ (progress bar) dùng conditional formatting hoặc SPARKLINE để trực quan hóa

Công thức tính "còn thiếu bao nhiêu để lên bậc" thường bị bỏ qua nhưng lại là phần tạo động lực thực sự — sale nhìn thấy "còn 3 triệu nữa là lên bậc 7%" sẽ chủ động gọi thêm khách trong ngày cuối tháng thay vì để trôi qua. Nếu team đang dùng thêm báo cáo bán hàng tổng thể, cấu trúc dashboard này có thể ghép chung với mẫu ở bài mẫu báo cáo bán hàng cho Google Sheets 2027 để không phải làm hai file riêng biệt.

Về mặt kỹ thuật, tránh để công thức bậc thang chạy trực tiếp trên hàng nghìn dòng giao dịch thô — sẽ làm chậm cả file khi dữ liệu tăng lên. Nên gộp trước bằng Pivot Table hoặc SUMIFS ra một bảng tổng hợp theo NV/tháng gọn (thường chỉ vài chục đến vài trăm dòng), rồi mới áp công thức bậc thang lên bảng tổng hợp đó. Cách này giữ file nhẹ và công thức dễ audit khi có tranh chấp lương.

Sai số thường gặp khi kiểm tra lại công thức

Ba lỗi phổ biến nhất khi rà soát file hoa hồng bậc thang trước khi chốt lương:

Thứ nhất, quên khóa vùng tham chiếu bảng bậc thang bằng dấu $ khi kéo công thức xuống các dòng khác — dẫn đến vùng tham chiếu bị lệch và ra kết quả sai hàng loạt mà không báo lỗi rõ ràng. Luôn dùng $D$2:$F$5 thay vì D2:F5 khi copy công thức cho nhiều nhân viên. Thứ hai, bảng bậc thang không được sắp xếp tăng dần theo Mức tối thiểu — VLOOKUP dạng gần đúng (TRUE) yêu cầu dữ liệu đã sort, nếu không sẽ trả về kết quả không đoán trước được, đôi khi đúng đôi khi sai tùy vị trí doanh số rơi vào. Thứ ba, nhầm giữa mức tối đa của bậc này và mức tối thiểu của bậc kế tiếp — nếu bậc 1 ghi "0-50.000.000" và bậc 2 ghi "50.000.000-100.000.000", đúng 50 triệu sẽ bị tính hai lần hoặc rơi vào vùng mập mờ tùy công thức dùng < hay <=. Cách an toàn là để mức tối thiểu của bậc sau bằng mức tối đa của bậc trước cộng 1 (hoặc dùng nhất quán toán tử so sánh xuyên suốt công thức).

Nếu công ty đang quản lý ngân sách chi hoa hồng như một khoản mục chi phí cố định hàng tháng để dự trù dòng tiền, việc theo dõi tổng chi hoa hồng thực tế so với dự toán cũng nên đưa vào cùng hệ thống theo dõi ngân sách — tham khảo thêm ở mẫu Google Sheets quản lý ngân sách hàng tháng để ghép khoản hoa hồng vào bức tranh chi phí tổng thể thay vì để rời rạc trong một file riêng.

Câu hỏi thường gặp

Hoa hồng theo bậc thang khác gì với hoa hồng cố định một mức?

Hoa hồng bậc thang chia doanh số thành nhiều khoảng (ví dụ dưới 50 triệu: 3%, 50-100 triệu: 5%, trên 100 triệu: 8%), mỗi khoảng áp dụng % khác nhau, thường tính luỹ tiến theo từng phần vượt ngưỡng chứ không áp 1 mức duy nhất cho toàn bộ doanh số.

Nên dùng hàm nào trong Google Sheets để tính hoa hồng bậc thang?

Hàm IFS phù hợp khi chỉ cần lấy % theo mức doanh số đạt được. Nếu cần tính luỹ tiến (mỗi phần doanh số nhân đúng % của bậc đó rồi cộng lại), phải kết hợp SUMPRODUCT với bảng ngưỡng, hoặc dùng VLOOKUP với tham số dò gần đúng (TRUE) để tra mức bậc.

File mẫu có tự động cập nhật khi thay đổi ngưỡng doanh số không?

Có, nếu đặt ngưỡng và tỷ lệ % trong bảng tham chiếu riêng (không hardcode trong công thức), khi sửa số liệu ở bảng tham chiếu, toàn bộ công thức IFS/VLOOKUP trong bảng tính hoa hồng sẽ tự cập nhật theo.

Có thể áp dụng mẫu này cho nhiều nhân viên cùng lúc không?

Được, chỉ cần liệt kê danh sách nhân viên và doanh số từng người theo hàng, công thức tính hoa hồng bậc thang kéo xuống áp dụng đồng loạt, kết hợp thêm SUMIF nếu cần gộp doanh số theo tháng hoặc theo nhóm sale.