- 01Lý do bắt đầu: “chi phí chưa phân loại cứ chồng lên”
- 02Quy trình của cơ chế
- 03Lấy các chi tiết chưa xử lý
- 04Chi tiết trong việc tìm email
- 05Quy tắc phân loại
- 06Đăng ký thành chi phí
- 07Định kỳ rà soát lại cả “chi phí bị nhầm vào danh mục khác”
- 08Quyết định cuối cùng giao cho chuyên gia
- 09Những gì cảm nhận được khi thực hiện
- 10Phù hợp với những ai
- 11Tổng kết
Chào buổi sáng, mình là まさきん.
Mình có một công việc làm thêm nhỏ đang duy trì với tư cách cá nhân. Việc ghi chép chi phí thì đã dùng SaaS kế toán, nhưng công đoạn nhớ lại “khoản dùng thẻ này là chi phí gì” vốn là một việc âm thầm tốn công.
Vì vậy mình đã tạo một cơ chế để AI đối chiếu chi tiết thẻ với hóa đơn trong email, tự động hóa luôn cả việc phân loại chi phí. Lần này mình giới thiệu cả cách gọi API và những cái bẫy thực tế mình đã gặp phải.
Lý do bắt đầu: “chi phí chưa phân loại cứ chồng lên”
Khi liên kết thẻ với SaaS kế toán, chi tiết sử dụng sẽ tự động được nạp vào. Nhưng chỉ vậy thì không biết được “đây là khoản thanh toán cho việc gì”. Cuối cùng phải dựa vào trí nhớ để phân loại sau.
Trí nhớ thì ngày càng mờ dần. Vì vậy mình quyết định giao hẳn công đoạn nhớ lại này cho AI.
Quy trình của cơ chế
Việc thực hiện gồm 4 giai đoạn sau:
- Lấy từ API của SaaS kế toán những chi tiết sử dụng thẻ chưa được phân loại
- Tìm email xác nhận đặt hàng hoặc hóa đơn có số tiền giống nhau, ngày gần nhau
- Đối chiếu cả hai để xác định nội dung
- Dựa vào nội dung đã xác định, phân loại loại chi phí rồi đăng ký thành giao dịch trong SaaS kế toán
Điểm mấu chốt là chỉ “chi tiết” hoặc chỉ “email” không đủ, phải đối chiếu cả hai mới xác định được nội dung.
Lấy các chi tiết chưa xử lý
Khi lấy chi tiết qua API của SaaS kế toán, mỗi chi tiết đều có một cờ thể hiện trạng thái xử lý. Để chỉ lấy các chi tiết chưa đăng ký, mình thu hẹp theo cờ này.
GET /api/1/wallet_txns
query: { company_id, start_date, end_date, limit: 100 }
Trong các chi tiết trả về, chỉ những mục có trạng thái “chưa đăng ký” và số tiền chưa khớp sổ lớn hơn 0 mới là đối tượng xử lý. Các chi tiết đã đăng ký hoặc đã đặt là bỏ qua sẽ bị loại khỏi đối tượng. Vì khoảng thời gian thường bị phân trang, mình chia thành nhiều khoảng thời gian để kiểm tra, tránh sót dữ liệu khi qua tháng.
Chi tiết trong việc tìm email
Nếu để AI đọc nguyên văn email, lượng thông tin quá nhiều có lúc sẽ chạm giới hạn token. Vì vậy mình thu hẹp điều kiện trước khi đưa nội dung vào.
Đầu tiên, mình tìm theo khoảng thời gian với địa chỉ gửi của email xác nhận đặt hàng hoặc hóa đơn.
search_threads query: "from:[email protected] after:2026/09/01 before:2026/09/30"
Dù tìm thấy email phù hợp, nếu đưa nguyên văn bản cho AI có lúc sẽ vượt giới hạn token. Trường hợp đó, mình tìm theo từ khóa trong file đã lưu nội dung email, chỉ trích ra những dòng có ghi số tiền hay tên sản phẩm.
# Ví dụ thu hẹp từ các file email đã lưu, chỉ giữ những email có số tiền và ngày gần nhau
grep -l "3,980円" ./mail_archive/*.eml | xargs grep -l "2026-09"
Khi thu hẹp bằng hai đầu mối là số tiền và ngày, số lượng ứng viên còn lại chỉ vài mục. Đến lúc đó mình mới đưa đúng phần liên quan cho AI đối chiếu. Nhiều email chỉ cần xem tiêu đề hoặc đoạn trích đầu là đủ, nên bí quyết là chỉ lấy đúng phạm vi cần thiết.
Trong các chi tiêu cần phân loại vào chi phí, cũng có cả chi phí cố định như cước điện thoại. Tiền điện thoại vừa dùng cho công việc cũng là loại chi phí dễ đau đầu khi tính tỷ lệ phân bổ. Nghĩ vậy, việc xem lại gói cước cũng có thể là một cách.
Khi bấm vào, trang đăng nhập Rakuten sẽ mở ra. Đăng nhập xong sẽ thấy nội dung chương trình.
Quy tắc phân loại
Sau khi xác định được nội dung, mình phân loại thành 3 loại sau:
| Phân loại | Nội dung | Cách xử lý |
|---|---|---|
| Chi phí trực tiếp của việc làm thêm | Vật tư tiêu hao, dịch vụ liên quan trực tiếp đến việc làm thêm | Tính vào chi phí kèm ghi chú tỷ lệ phân bổ cho công việc |
| Sách tham khảo, tài liệu | Sách phục vụ hiểu biết nghiệp vụ | Tính là chi phí tài liệu thông thường |
| Chi tiêu cá nhân | Mua sắm cá nhân không liên quan đến việc làm thêm | Loại khỏi chi phí, xử lý như rút vốn của chủ doanh nghiệp |
Những khoản khó phân loại, mình không cố ép vào phía chi phí. Những chi tiêu chưa chắc chắn trong phán đoán, mình tạm coi là chi tiêu cá nhân, rồi đánh dấu để xem lại sau.
Đăng ký thành chi phí
Sau khi quyết định phân loại, mình đăng ký thành giao dịch qua API của SaaS kế toán.
POST /api/1/deals
body: {
company_id,
issue_date: "2026-09-15",
type: "expense",
details: [{
account_item_id: <ID khoản mục chi phí>,
amount: <số tiền>,
description: "◯◯ 消耗品(事業按分の注記)"
}],
payments: [{
amount: <số tiền>, date: "2026-09-15",
from_walletable_type: "credit_card", from_walletable_id: <ID thẻ>
}]
}
Ở đây có một điểm cần lưu ý. Việc đăng ký này bên trong SaaS kế toán là thao tác “tạo mới một giao dịch”, không tự động liên kết — khớp sổ — với chi tiết chưa xử lý ban đầu. Chỉ đăng ký giao dịch thôi thì trạng thái của chi tiết vẫn giữ nguyên là chưa xử lý.
Vì vậy sau khi đăng ký xong, mình luôn thực hiện thao tác liên kết bằng tay giữa chi tiết và giao dịch vừa tạo, trên màn hình của SaaS kế toán. Nếu bỏ qua bước này, cùng một khoản chi sẽ bị tính hai lần, nên mình luôn để tâm đến điểm này.
Định kỳ rà soát lại cả “chi phí bị nhầm vào danh mục khác”
Dù đã tự động hóa, lỗi phân loại vẫn không thể về 0. Vì vậy mỗi tháng một lần, mình để AI rà soát xem có ghi chép nào có vẻ liên quan đến việc làm thêm nhưng vẫn đang bị để ở danh mục thông thường không.
Cụ thể, mình lấy báo cáo kết quả kinh doanh qua API, xác định các chi phí đang được tính vào khoản mục thông thường thay vì khoản mục riêng cho việc làm thêm. Sau đó, mình lấy chi tiết của từng khoản mục qua API danh sách giao dịch, để AI trích xuất và liệt kê những ghi chép có vẻ “nên chuyển về danh mục việc làm thêm” dựa vào từ khóa trong phần tóm tắt hay xu hướng số tiền.
Khi tìm được giao dịch phù hợp, mình dùng PUT để thay đổi khoản mục.
PUT /api/1/deals/{ID giao dịch}
body: { company_id, issue_date, type: "expense",
details: [{ id: <ID chi tiết hiện có>, account_item_id: <ID khoản mục đúng>, amount, description }] }
Ở đây cũng có một điểm cần lưu ý. Nếu gửi đi mà không kèm ID chi tiết hiện có trong details, hệ thống sẽ coi đó là thêm mới chứ không phải cập nhật. Việc giữ nguyên ID hiện có là điều kiện bắt buộc để chuyển đổi đúng cách.
Những mục được trích xuất, mình tự kiểm tra nội dung rồi chỉ thay đổi những mục cần thiết.
Quyết định cuối cùng giao cho chuyên gia
Đây là điểm mình muốn nhấn mạnh lại. Cơ chế này chỉ giúp tăng hiệu quả cho công đoạn “chuẩn bị trước khi vào sổ”. Quyết định cuối cùng về phân loại chi phí hay tính hợp lý của tỷ lệ phân bổ, mình luôn theo phán đoán của chuyên gia như kế toán viên thuế.
Phân loại của AI chỉ là phương án ban đầu. Đặc biệt phần liên quan đến tỷ lệ phân bổ công việc, mình không tự quyết định một mình mà luôn vận hành với tiền đề sẽ xác nhận lại với chuyên gia.
Những gì cảm nhận được khi thực hiện
Điều giúp ích nhất là công việc nhớ lại “đây là khoản thanh toán cho việc gì” đã biến mất. Chỉ cần còn dấu vết ghi chép trong email, việc xác định nội dung có thể giao cho AI.
Mặt khác, mình luôn tự mắt kiểm tra lần cuối việc phân loại. Đặc biệt ranh giới giữa chi tiêu cá nhân và chi phí là phần mình cảm thấy rủi ro nếu chỉ dựa vào phán đoán máy móc.
Phù hợp với những ai
- Người làm thêm hoặc kinh doanh cá nhân có nhiều chi phí thanh toán bằng thẻ, hay bị dồn việc vào sổ về sau
- Người có nhiều giao dịch còn lưu email xác nhận đặt hàng hay hóa đơn
- Người đã tương đối quen với việc kết nối API của SaaS kế toán hay ứng dụng AI
Tổng kết
Ý tưởng đối chiếu chi tiết thẻ với email tự nó không phải điều gì đặc biệt. Nhưng việc tự làm mỗi lần hay giao cho một cơ chế sẽ tạo ra khác biệt lớn về công sức phải bỏ ra.
Nếu nắm được cả cái bẫy rằng chỉ đăng ký qua API thì chưa khớp sổ với chi tiết, khi thực sự bắt tay làm sẽ ít vướng mắc hơn. Mình cảm thấy đã cơ chế hóa tốt phần chuẩn bị trước, mà vẫn giữ nguyên tắc để quyết định cuối cùng cho chuyên gia.
Qua quá trình sắp xếp này, cước điện thoại cũng trở thành đối tượng cần xem lại. Tiền điện thoại vừa dùng cho công việc là khoản chi khiến mình đau đầu nhất khi phân bổ. Vậy thì có lẽ nên sắp xếp lại chính gói cước trước.
Khi bấm vào, trang đăng nhập Rakuten sẽ mở ra. Đăng nhập xong sẽ thấy nội dung chương trình.
Bài viết này có chứa quảng cáo liên kết. Nếu bạn đăng ký sản phẩm hoặc dịch vụ qua liên kết trên trang này, chúng tôi có thể nhận được hoa hồng từ đối tác. Ngoài ra, người vận hành trang là nhân viên của Rakuten Group và có thể nhận thù lao qua chương trình giới thiệu nhân viên. Nội dung và đánh giá trong bài được viết dựa trên trải nghiệm thực tế và tìm hiểu của người vận hành, không phụ thuộc vào việc có quảng cáo hay không, nhưng mong bạn đọc với sự hiểu biết về mối quan hệ trên. Chi tiết xem tại phần Miễn trừ trách nhiệm & Tiết lộ liên kết. Miễn trừ trách nhiệm & Tiết lộ liên kết
Bài viết này có sử dụng dịch máy. Vui lòng tham khảo trang đa ngôn ngữ trên website chính thức của Rakuten Mobile để biết điều kiện chính xác.
Nếu bạn có thắc mắc về khu vực phủ sóng hoặc chất lượng tín hiệu của Rakuten Mobile, có thể liên hệ qua mẫu đề nghị khảo sát và cải thiện sóng chính thức.