ezBookkeeping: sổ chi tiêu tự lưu trữ cho agency marketing số
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
ezBookkeeping: sổ chi tiêu tự lưu trữ, đáng thử ở mức nội bộ nhưng chưa phải phần mềm kế toán
ezBookkeeping là một ứng dụng quản lý tài chính cá nhân mã nguồn mở, viết chủ yếu bằng Go và giao diện web, dành cho người muốn tự giữ dữ liệu thu chi trên máy chủ của mình. README mô tả đây là ứng dụng tự lưu trữ (self-hosted), ghi giao dịch hằng ngày, nhập dữ liệu từ nhiều nguồn, tìm kiếm, lọc và vẽ biểu đồ phân tích [1]. Bài này xem xét liệu một agency marketing số có thể mượn công cụ ấy làm sổ theo dõi chi tiêu vận hành hay không.
Khuyến nghị ngắn gọn: nên cân nhắc cho một thử nghiệm nhỏ, có phạm vi rõ, nơi một hoặc vài người cùng ghi nhận khoản chi như quảng cáo ứng trước, công cụ trả phí theo tháng và thanh toán cho cộng tác viên. Lý do là phần mềm nhẹ, cài bằng một lệnh Docker, hỗ trợ đa tiền tệ, giao dịch định kỳ và đính kèm ảnh chứng từ [1]. Đó là các nhu cầu có thật của một agency quy mô nhỏ.
Không nên coi nó là hệ thống kế toán doanh nghiệp. Nguồn tôi đọc tự định nghĩa sản phẩm là ứng dụng tài chính cá nhân, và không nói đến hóa đơn điện tử, thuế hay chuẩn mực kế toán của Việt Nam [1]. Nếu agency cần sổ sách để nộp cho cơ quan thuế, phần mềm kế toán có chứng từ hợp lệ vẫn là lựa chọn bắt buộc; ezBookkeeping chỉ có thể là lớp ghi chép phụ, và phải có người chịu trách nhiệm đối chiếu sang sổ chính thức.
Chi tiêu của agency nằm rải rác ở thẻ, ví và bảng tính
Một agency marketing số cỡ vài chục người thường có dòng tiền phức tạp hơn vẻ ngoài. Ngân sách quảng cáo của khách hàng có lúc agency ứng trước bằng thẻ công ty, phí phần mềm thiết kế, lên lịch bài và báo cáo trả theo tháng bằng nhiều đồng tiền, còn tiền cho người quay dựng hay người viết nội dung ngoài lại chuyển theo từng việc. Khi các khoản này nằm trong tin nhắn, ảnh chụp màn hình và bảng tính cá nhân, cuối tháng rất khó trả lời câu hỏi đơn giản: chiến dịch nào đã tiêu bao nhiêu.
Bài toán ở đây không phải lập báo cáo tài chính mà là có một nơi ghi nhanh, tìm lại nhanh và nhìn được xu hướng. README của ezBookkeeping nhắm đúng tầm đó: ghi giao dịch, lọc và tìm hóa đơn, xem biểu đồ lịch sử, thậm chí tự chọn chiều dữ liệu cho truy vấn riêng [1]. Mức độ này đủ cho câu hỏi quản trị nội bộ, nhưng chưa đủ cho nhu cầu đối soát với ngân hàng hay xuất hóa đơn.
Một tệp thực thi Go phục vụ cả máy tính lẫn điện thoại
Từ những gì README cho thấy, ezBookkeeping là một chương trình duy nhất: người dùng tải bản nhị phân và chạy lệnh server run, hoặc chạy ảnh Docker, rồi mở trình duyệt vào cổng 8080 mặc định [1]. Không có mô tả về nhiều dịch vụ tách rời hay hàng đợi riêng. Giao diện được thiết kế riêng cho di động và máy tính để bàn, đồng thời hỗ trợ PWA, tức web có thể thêm vào màn hình chính và dùng gần giống ứng dụng gốc [1].
Về lưu trữ, tài liệu nêu SQLite, MySQL và PostgreSQL [1]. Đây là lựa chọn kiến trúc quan trọng với agency: SQLite phù hợp bản thử một người hoặc nhóm rất nhỏ, còn MySQL hay PostgreSQL hợp lý hơn nếu muốn sao lưu và vận hành giống các hệ thống khác trong công ty. Bài viết không có số liệu về sức chịu tải của từng loại cơ sở dữ liệu, nên mọi so sánh hiệu năng đều để cho bước thử nghiệm.
Mô hình dữ liệu có hai tầng tài khoản và hai tầng hạng mục, cùng đính kèm ảnh, vị trí trên bản đồ và giao dịch lên lịch [1]. Có thể đọc điều này như một khung đủ linh hoạt để ánh xạ cấu trúc agency: tài khoản cấp một là thẻ hay ví, cấp hai là từng thẻ cụ thể; hạng mục cấp một là loại chi phí, cấp hai là chi tiết. Việc ánh xạ khách hàng hay chiến dịch vào cấu trúc này là đề xuất của bài, không phải mẫu có sẵn trong dự án.
Từ một dòng chi tiêu trên điện thoại đến biểu đồ cuối tháng
Hãy theo một khoản chi giả định: nhân viên trả tiền chạy quảng cáo bằng thẻ công ty. Họ mở giao diện di động, chọn tài khoản, hạng mục, nhập số tiền, đồng tiền và đính kèm ảnh biên nhận. README xác nhận có ghi giao dịch, ảnh đính kèm và nhiều đồng tiền cùng nguồn tỷ giá tự cập nhật [1]. Từ đây bản ghi nằm trong cơ sở dữ liệu của máy chủ tự lưu trữ, không đi qua dịch vụ đám mây của tác giả.
Nhánh thứ hai là nhập hàng loạt. Dự án liệt kê nhiều định dạng nhập như CSV, Excel, OFX, QIF, MT940, Camt.053, GnuCash, Firefly III và Beancount, kèm ánh xạ cột, quy tắc và kịch bản tùy chỉnh cho CSV hoặc Excel [1]. Với agency, đường đi hợp lý là xuất sao kê ngân hàng, nhập vào ezBookkeeping, rồi gán hạng mục. Tôi chưa có căn cứ để nói ngân hàng Việt Nam xuất định dạng nào tương thích, vì tài liệu đã đọc không đề cập.
Những gì nguồn đã đọc xác nhận có trong phiên bản này
Theo README tại commit đã ghim, phần ghi chép gồm tài khoản và hạng mục hai cấp, ảnh đính kèm giao dịch, theo dõi vị trí bằng bản đồ, giao dịch lên lịch, cùng tìm kiếm, lọc và trực quan hóa nâng cao [1]. Về quốc tế hóa có nhiều ngôn ngữ, nhiều đồng tiền, nhiều nguồn tỷ giá tự cập nhật, nhiều múi giờ và định dạng ngày, số, tiền tệ tùy chỉnh [1]. Bảng bản dịch trong README có dòng tiếng Việt [1].
Nhóm tính năng AI gồm nhận dạng văn bản và ảnh biên nhận, tạo biểu đồ tùy chỉnh bằng AI, giao thức MCP (Model Context Protocol, chuẩn để công cụ AI gọi vào ứng dụng khác), Agent Skill và script dòng lệnh gọi API [1]. Nguồn không nói mô hình nào chạy bên dưới, dữ liệu có rời khỏi máy chủ hay không, hay độ chính xác nhận dạng ra sao. Vì vậy phần này nên xếp vào loại tính năng có tồn tại nhưng chưa được đánh giá.
Về bảo mật có xác thực hai yếu tố, đăng nhập ngoài bằng OIDC, giới hạn tần suất đăng nhập, khóa ứng dụng bằng mã PIN hoặc WebAuthn [1]. Tệp Agent Skill còn mô tả script ebktools dùng để ghi giao dịch mới, truy vấn giao dịch, lấy thông tin tài khoản, hạng mục, nhãn và dữ liệu tỷ giá [3]. Chưa thấy nguồn nào nói về phân quyền theo vai trò, quy trình phê duyệt hay nhật ký kiểm toán; đừng mặc định chúng có.
Ai nên dùng và ai không nên
Nhóm phù hợp nhất là cá nhân và nhóm nhỏ biết tự vận hành máy chủ: chủ agency muốn có sổ chi nội bộ, người làm tự do quản lý nhiều đồng tiền, hay phòng vận hành cần công cụ thử nghiệm trước khi chọn giải pháp lớn. README nhấn mạnh phần mềm tiết kiệm tài nguyên, chạy được trên máy chủ gia đình, NAS và Raspberry Pi [1]. Điều này giảm rào cản phần cứng, nhưng không thay thế được trách nhiệm sao lưu.
Nhóm không phù hợp là doanh nghiệp cần nhiều pháp nhân, nhiều bộ phận có quyền xem khác nhau, hay cần luồng duyệt chi. Nguồn đã đọc mô tả sản phẩm như ứng dụng cá nhân, và tôi không tìm thấy mô tả về cấu trúc tổ chức nhiều tầng [1]. Nếu bộ phận kế toán đã dùng phần mềm riêng, việc thêm một công cụ chạy song song chỉ hợp lý khi nó giải quyết một khoảng trống cụ thể.
Tình huống giả định: sổ chi chiến dịch của một agency marketing số ở TP.HCM
Hãy tưởng tượng một agency marketing số hai mươi lăm người, chuyên chạy quảng cáo và sản xuất nội dung cho khoảng chục thương hiệu bán lẻ. Đây là kịch bản đề xuất, không phải ca đã xảy ra. Hiện tại trưởng nhóm vận hành giữ một bảng tính chung, còn các khoản trả bằng thẻ phát sinh từ nhiều người. Agency muốn thử ezBookkeeping trong một quý để xem có thay được bảng tính ấy ở khâu ghi chi tiêu hay không.
Thiết kế đề xuất: tài khoản cấp một là Thẻ công ty, Ví chuyển khoản, Tiền mặt tạm ứng; tài khoản cấp hai là từng thẻ hoặc từng người giữ quỹ. Hạng mục cấp một gồm Quảng cáo ứng trước, Công cụ, Cộng tác viên, Sản xuất; cấp hai ghi chi tiết nền tảng hoặc loại việc. Tên chiến dịch được đưa vào nhãn hoặc mô tả theo quy ước thống nhất. Tính năng giao dịch lên lịch dùng để nhập trước các khoản phần mềm thu đều mỗi tháng [1], và ảnh đính kèm lưu biên nhận.
Điều bài không khẳng định: không nói phần mềm hỗ trợ đồng Việt Nam theo cách nào, vì README chỉ nói đa tiền tệ [1]. Cũng không nói ứng dụng thay được việc xuất hóa đơn cho khách. Vai trò thực tế của nó là sổ nháp có kỷ luật: cuối tháng kế toán đối chiếu vài hạng mục lớn với sổ chính thức, xem còn thiếu chứng từ nào. Nếu việc đối chiếu cho thấy sai lệch lớn, đó là bằng chứng quy ước nhập liệu cần chỉnh, chứ chưa nói được gì về chất lượng phần mềm.
Cài đặt, dữ liệu bền vững và sao lưu
Cách khởi động nhanh nhất theo README là một lệnh docker run, ánh xạ cổng 8080; có cả thẻ latest-snapshot cho bản dựng hằng ngày [1]. Chính README cảnh báo rằng dùng cho sản xuất cần gắn volume bền vững để tránh mất dữ liệu [1]. Với agency, điều này nghĩa là phải quyết định ngay từ ngày đầu: volume nằm ở đâu, cơ sở dữ liệu là SQLite hay MySQL, ai chịu trách nhiệm sao lưu và kiểm tra khôi phục.
Cài từ bản nhị phân và dựng từ mã nguồn cũng được hỗ trợ; dựng từ mã nguồn cần Go, GCC, Node.js và npm, có thể đóng gói thành tệp nén hoặc ảnh Docker [1]. Thông thường một agency không nên dựng từ mã nguồn trừ khi muốn sửa giao diện. Nên ghim phiên bản phát hành cụ thể thay vì dùng bản snapshot hằng ngày, vì bản snapshot là bản dựng thử, mức ổn định chưa được nguồn nêu.
Về tích hợp tự động, script ebktools cần hai biến môi trường là địa chỉ máy chủ và token API, có thể đặt trong tệp .env ở thư mục người dùng [3]. Token thuộc nhóm bí mật vận hành: không nên để trong kho mã chung. Việc nâng cấp phiên bản, ghi chú thay đổi cơ sở dữ liệu và quy trình sao lưu trước khi nâng cấp cần đọc thêm trong tài liệu chính thức; các tệp đã đọc không bàn tới.
Quyền riêng tư, xác thực và phần chưa có bằng chứng
Lợi thế rõ nhất là dữ liệu nằm trên máy chủ do agency kiểm soát, đúng với mục tiêu quyền riêng tư và kiểm soát mà README nêu [1]. Các lớp bảo vệ được liệt kê gồm xác thực hai yếu tố, OIDC, giới hạn tần suất đăng nhập và khóa ứng dụng bằng PIN hoặc WebAuthn [1]. Nếu agency đã có nhà cung cấp danh tính dùng OIDC, việc tích hợp có thể giảm số mật khẩu phải quản lý.
Rủi ro vận hành nằm ở phía agency. Chạy phần mềm tài chính trên cổng 8080 mà không đặt sau HTTPS, không giới hạn truy cập mạng, hay không có quy trình thu hồi token sẽ làm vô hiệu các tính năng bảo mật trên. Ảnh biên nhận có thể chứa số thẻ, tên khách hàng hoặc thông tin cá nhân của cộng tác viên, nên cần chính sách lưu trữ và quyền truy cập trước khi đưa vào.
Nhóm tính năng AI đặt ra câu hỏi riêng. Nếu nhận dạng biên nhận hay tạo biểu đồ gọi tới dịch vụ mô hình bên ngoài, ảnh và số liệu sẽ rời máy chủ; nguồn đã đọc không cho biết điều đó có xảy ra hay không [1]. Cho tới khi đọc xong tài liệu cấu hình của tính năng này, hãy tắt hoặc thử trên dữ liệu giả. Tôi cũng không tìm thấy trong các tệp đã đọc một chính sách báo cáo lỗ hổng, nên chưa thể nói quy trình xử lý sự cố bảo mật của dự án.
MIT cho mã nguồn, nhưng chưa bao phủ dữ liệu và dịch vụ quanh nó
Tệp LICENSE tại commit đã ghim là giấy phép MIT, bản quyền ghi 2020-2026 MaysWind [2]. MIT cho phép dùng, sao chép, sửa, hợp nhất, phát hành, cấp phép lại và bán bản sao với điều kiện giữ nguyên thông báo bản quyền và nội dung giấy phép trong các bản sao đáng kể; phần mềm được cung cấp nguyên trạng, không bảo hành [2]. Đối với agency chỉ dùng nội bộ, nghĩa vụ này gần như không tạo gánh nặng.
Có hai điểm cần lưu ý. Thứ nhất, giấy phép này áp dụng cho mã nguồn ở commit đã kiểm tra, không đương nhiên áp dụng cho mô hình AI, dịch vụ tỷ giá, bản đồ hay các thư viện bên thứ ba mà ứng dụng dùng. Tệp licenses.ts cho thấy giao diện có hàm trả về chuỗi giấy phép chính và danh sách giấy phép bên thứ ba, giá trị được nhúng khi dựng ứng dụng [4]; danh sách thực tế phải xem trong bản dựng cụ thể.
Thứ hai, tôi không thấy trong các tệp đã đọc điều khoản CLA, thư mục ngoại lệ hay chính sách nhãn hiệu. Việc không thấy không chứng minh chúng không tồn tại ở nơi khác. Dự án cũng có bản chạy thử công khai và tài liệu riêng ở tên miền của tác giả [1], nhưng đó là dịch vụ do tác giả vận hành; bài không đánh giá điều khoản của chúng.
Chi phí: chủ yếu là thời gian thiết kế quy ước và giữ kỷ luật nhập liệu
Không có giá cấp phép, nhưng không có nghĩa là không tốn. Các loại nguồn lực gồm: một máy chủ nhỏ hoặc máy ảo (README nói phần mềm chạy được trên thiết bị rất khiêm tốn [1]), dung lượng lưu trữ cho cơ sở dữ liệu và ảnh chứng từ, một người dựng và bảo trì, và thời gian của nhân viên nhập liệu. Tôi không đưa con số tiền vì không có nguồn đã đọc để làm căn cứ.
Giả định khi lập kế hoạch: nhóm thử nghiệm gồm ba đến năm người nhập liệu, một người quản trị bán thời gian, dữ liệu chủ yếu là giao dịch và ảnh biên nhận cỡ nhỏ. Với giả định ấy chi phí hạ tầng thường nhỏ hơn nhiều so với chi phí thời gian. Chi phí ẩn lớn nhất là chuyển dữ liệu cũ vào, làm sạch hạng mục và đào tạo thói quen ghi ngay khi chi.
So với bảng tính, phần mềm kế toán và các sổ chi tiêu tự lưu trữ khác
Bảng tính chung linh hoạt nhất và quen thuộc nhất, nhưng không có nhập liệu tối ưu cho điện thoại, không có giao dịch lên lịch và rất dễ bị sửa nhầm. ezBookkeeping đổi sự linh hoạt đó lấy cấu trúc: tài khoản, hạng mục, nhãn và lịch sử có hệ thống [1]. Nếu nhóm chưa kỷ luật, cấu trúc đó có thể thành gánh nặng chứ không thành lợi thế.
Phần mềm kế toán doanh nghiệp là nhóm phương án khác về bản chất: chúng gắn với chứng từ, thuế, công nợ và báo cáo theo quy định. ezBookkeeping không nhằm thay thế nhóm này, và README không đưa ra tuyên bố như vậy [1]. Nên coi hai loại bổ sung nhau: phần mềm kế toán là sổ pháp lý, ezBookkeeping là sổ quản trị nhanh.
Những điều kiện khiến không nên dùng, hoặc nên dừng thử nghiệm
Giới hạn đầu tiên là phạm vi sản phẩm: README gọi nó là ứng dụng tài chính cá nhân [1]. Doanh nghiệp cần phân quyền theo vai trò, luồng duyệt chi, hợp nhất nhiều công ty hay xuất báo cáo theo mẫu pháp lý sẽ không tìm được điều đó trong nguồn đã đọc. Đừng bù khoảng trống này bằng suy đoán.
Giới hạn thứ hai là phụ thuộc vào một bộ duy trì chính. Kho mã thuộc tài khoản cá nhân của tác giả và giấy phép nêu bản quyền của một cá nhân [2]. Điều này không có nghĩa dự án kém, nhưng agency nên có kế hoạch rút lui: xuất dữ liệu định kỳ, giữ bản sao của bản nhị phân đang dùng, và theo dõi tần suất phát hành.
Giới hạn thứ ba nằm ở phần AI chưa được xác minh về quyền riêng tư và độ chính xác [1]. Không nên cho nhân viên chụp biên nhận có thông tin nhạy cảm vào tính năng nhận dạng trước khi biết dữ liệu đi đâu. Ngoài ra, phần phụ thuộc vào nguồn tỷ giá tự động có thể thay đổi hoặc lỗi; mọi quyết định có giá trị lớn cần dùng tỷ giá do kế toán xác nhận.
Kế hoạch thử mười hai tuần với tiêu chí đo được
Giai đoạn một, tuần một đến hai: dựng bản chạy trên máy chủ thử, gắn volume bền vững, ghim phiên bản phát hành, bật xác thực hai yếu tố, và kiểm tra khôi phục từ bản sao lưu. Xây cấu trúc tài khoản, hạng mục cho một nhóm khách hàng. Tiêu chí qua: khôi phục thành công từ bản sao lưu trong một lần thử, và xuất được toàn bộ giao dịch ra tệp mở.
Giai đoạn hai, tuần ba đến tám: ba đến năm người nhập chi tiêu thật song song với bảng tính cũ. Đo tỷ lệ khoản chi được nhập trong ba ngày kể từ khi phát sinh, tỷ lệ giao dịch có biên nhận đính kèm, và chênh lệch tổng chi theo hạng mục lớn giữa hai nguồn. Ngưỡng đề xuất, do nhóm tự đặt: ít nhất chín phần mười khoản chi được nhập đúng hạn. Ngưỡng này là đề xuất, không phải chuẩn ngành.
Giai đoạn ba, tuần chín đến mười hai: thử nhập sao kê, giao dịch lên lịch và, nếu muốn, script ebktools trên dữ liệu giả. Tiêu chí dừng: nếu chênh lệch với sổ chính thức liên tục vượt mức kế toán chấp nhận, nếu nhân viên quay lại bảng tính, hoặc nếu phát hiện dữ liệu rời máy chủ ngoài ý muốn, dừng và rút dữ liệu. Tiêu chí tiếp tục: kế toán dùng báo cáo của hệ thống để chuẩn bị đối chiếu cuối tháng và tiết kiệm thời gian đo được so với trước.
Kết luận: một sổ nháp có kỷ luật, không phải bộ máy kế toán
ezBookkeeping đáng để một agency marketing số thử trong phạm vi hẹp. Nó gọn, cài nhanh, hỗ trợ đa tiền tệ, giao dịch lên lịch, nhập dữ liệu từ nhiều định dạng và có các lớp bảo vệ tài khoản thông dụng, tất cả theo mô tả tại README đã ghim [1]. Giấy phép MIT làm rào cản pháp lý nội bộ rất thấp [2].
Những gì còn chưa biết cũng quan trọng không kém: cách tính năng AI xử lý dữ liệu, mức độ hỗ trợ đồng Việt Nam, khả năng phân quyền, quy trình nâng cấp. Tất cả cần được xác minh bằng tài liệu chính thức và bằng thử nghiệm trước khi giao cho dữ liệu thật. Bài này chỉ là nghiên cứu tại bàn, không thay cho việc đó.
Nếu thử nghiệm đạt các tiêu chí đã nêu, bước tiếp theo hợp lý là viết quy ước hạng mục thành tài liệu chung và xác định rõ ranh giới giữa sổ quản trị với sổ kế toán. Nếu không đạt, chi phí phải trả chỉ là vài tuần công sức và một bản dữ liệu xuất ra, miễn là kế hoạch rút lui đã được chuẩn bị từ đầu.
Nguồn, mốc kiểm tra và giới hạn của nghiên cứu
Dự án được chọn từ kho lưu trữ GitHub Trending có sẵn: ezBookkeeping xuất hiện 8 lần trong danh sách Go, lần đầu ngày 2026-01-20 ở vị trí 16, lần cuối ngày 2026-07-22 [5]. Kho lưu trữ chỉ bao gồm các danh sách Python, Go, JavaScript và Swift, thiếu hai ngày 2026-09-03 và 2026-10-12, và không phải bảng xếp hạng chính thức của top 100. Trang bằng chứng được trích dẫn là trang ngày đầu tiên [5].
Mã nguồn được cố định ở commit 9cb3a08e6be6c13dfa95b22ec2ad89b710802f76, ngày 2026-10-09; việc kiểm tra thực hiện ngày 2026-10-12. Các tệp đã đọc là README, LICENSE, tệp Agent Skill và tệp licenses.ts [1][2][3][4]. Siêu dữ liệu GitHub ghi bản phát hành mới nhất lúc thu thập là v2.0.1; thông tin này không nằm trong các nguồn trích dẫn.
Đây là nghiên cứu tại bàn: chưa cài đặt, chưa chạy, chưa đo hiệu năng hay bảo mật. Mọi tình huống ở Việt Nam là đề xuất giả định. Bài không phải công trình khoa học đã qua bình duyệt và không thay cho tư vấn kế toán, pháp lý hay an ninh thông tin. Nội dung trong kho mã được xem là dữ liệu tham khảo, không phải chỉ dẫn.
Xem mã nguồn ezBookkeeping trên GitHub