Giới thiệu dự án

Trong bối cảnh nền kinh tế số và thị trường bán lẻ năng lượng cạnh tranh gay gắt, ngành kinh doanh nhiên liệu (xăng, dầu diesel, khí hóa lỏng) đòi hỏi quy trình luân chuyển vốn nhanh và kiểm soát thanh khoản nghiêm ngặt. Theo thống kê tài chính từ Hiệp hội Xăng dầu Việt Nam, chi phí hàng tồn kho và các khoản công nợ thương mại chiếm từ 45% đến 65% tổng tài sản lưu động của các doanh nghiệp kinh doanh xăng dầu vừa và nhỏ (SMEs). Việc quản lý thiếu đồng bộ giữa dòng hàng và dòng tiền dễ dẫn đến nguy cơ đứt gãy dòng tiền hoạt động (operating cash flow), tăng tỷ lệ nợ khó đòi và suy giảm hiệu quả sử dụng vốn lưu động (working capital).

Đề tài "Hoàn thiện công tác kế toán thanh toán với người mua, người bán tại Công ty Cổ phần Thương mại Bảo Hưng Long" (Mã sinh viên: 1712401030, Chuyên ngành Kế toán – Kiểm toán, Trường Đại học Quản lý và Công nghệ Hải Phòng) tập trung giải quyết các điểm nghẽn cốt lõi trong chuỗi thanh toán doanh nghiệp thương mại xăng dầu.

[Nhà cung cấp (Bên Bán)] ---> (Hóa đơn GTGT, Giấy báo Nợ) ---> [Kế toán TK 331]
                                                            (Đối chiếu & Hạch toán)
[Khách hàng (Bên Mua)]  <--- (Hóa đơn GTGT, Giấy báo Có) <--- [Kế toán TK 131]

Vấn đề thực tiễn và bài toán kỹ thuật

Tại Công ty Cổ phần Thương mại Bảo Hưng Long – doanh nghiệp thành lập từ năm 2009 chuyên phân phối xăng E5-RON 92, RON 95-III, dầu DO 0.05S-II và hóa dầu – thực trạng công tác kế toán công nợ phải đối mặt với các nút thắt kỹ thuật:

  • Xung đột ghi nhận thời gian thực: Việc đối soát công nợ thanh toán chậm (chuyển khoản, mở hạn mức tín dụng theo lô) và thanh toán ngay (tiền mặt tại cột bơm) gặp độ trễ ghi sổ từ 24h đến 72h.
  • Rủi ro kiểm soát ranh giới 20 triệu đồng: Quy định pháp lý về thuế GTGT yêu cầu hóa đơn từ 20 triệu đồng trở lên bắt buộc phải chuyển khoản qua ngân hàng. Việc thiếu cơ chế cảnh báo tự động dễ dẫn đến rủi ro bị loại chi phí khấu trừ thuế theo chuẩn mực pháp lý.
  • Áp lực hạch toán thủ công theo Thông tư 200/2014/TT-BTC: Khối lượng nghiệp vụ phát sinh hàng ngày lớn nhưng phân tán qua Sổ Nhật ký chung, Sổ cái, Sổ chi tiết TK 131 và TK 331, gây nguy cơ sai lệch số dư cuối kỳ giữa sổ chi tiết và sổ tổng hợp.

Mục tiêu dự án

  1. Chuẩn hóa quy trình hạch toán: Tối ưu hóa mô hình kế toán Nhật ký chung trên nền tảng kỹ thuật số, đảm bảo tuân thủ 100% chuẩn mực Thông tư 200/2014/TT-BTC.
  2. Xây dựng hệ thống cảnh báo và phân loại nợ tự động: Thiết lập thuật toán phân tích tuổi nợ (Aging of Accounts Receivable/Payable) và cảnh báo kỳ hạn nợ đến hạn (Due-date tracking).
  3. Giảm độ trễ đối soát: Rút ngắn thời gian đối chiếu công nợ giữa kế toán kho, kế toán ngân hàng và thủ quỹ từ 48 giờ xuống dưới 4 giờ.
  4. Tối ưu hóa vòng quay khoản phải thu (Receivables Turnover Ratio): Cắt giảm tỷ lệ nợ quá hạn từ 6.8% xuống dưới 1.5% tổng dư nợ.

Phạm vi và giới hạn

  • Phạm vi nghiệp vụ: Toàn bộ chu trình mua hàng – công nợ phải trả (P2P - Procure to Pay) trên TK 331 và chu trình bán hàng – công nợ phải thu (O2C - Order to Cash) trên TK 131.
  • Phạm vi kỹ thuật: Áp dụng cho hệ thống bán lẻ qua mạng lưới cửa hàng xăng dầu chuyên doanh và bán buôn theo hợp đồng hạn mức tại khu vực Hải Phòng và phụ cận.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Khảo sát mô hình vận hành tại doanh nghiệp cho thấy cấu trúc dòng chứng từ truyền thống bộc lộ nhiều điểm nghẽn khi khối lượng giao dịch tăng trưởng:

Tiêu chí Mô hình truyền thống (Thủ công / Excel rời rạc) Mô hình đề xuất (Kế toán số hóa tích hợp)
Tốc độ ghi sổ Chậm (nhập liệu kép vào Sổ NKC và Sổ chi tiết) Tức thời (Real-time synchronization qua CSDL quan hệ)
Độ chính xác Rủi ro sai sót định khoản, trùng lặp chứng từ Kiểm tra toàn vẹn dữ liệu (Foreign key constraints)
Kiểm soát tuổi nợ Lập báo cáo thủ công cuối tháng Phân tích tự động theo dải: <30 ngày, 31-60 ngày, >90 ngày
Đối soát ngân hàng Khớp thủ công Giấy báo Nợ/Có và Ủy nhiệm chi Đối chiếu tự động qua Banking API / Sao kê điện tử
Khả năng mở rộng Giới hạn 1 người/tệp tin, dễ phân mảnh dữ liệu Đa người dùng, phân quyền chi tiết (RBAC)

Phân tích yêu cầu hệ thống theo mô hình MoSCoW

  • Must-have (Bắt buộc):
    • Tự động hóa bút toán kép: $Nợ\ TK\ 131/Có\ TK\ 511, 3331$ và $Nợ\ TK\ 156, 1331/Có\ TK\ 331$.
    • Kiểm tra điều kiện thanh toán $\ge 20.000.000\ VNĐ$ bắt buộc chỉ định tài khoản tiền gửi ngân hàng (TK 1121).
    • Khóa sổ và xuất Bảng cân đối số phát sinh tự động cân bằng giữa Tổng Nợ và Tổng Có.
  • Should-have (Nên có):
    • Trích lập tự động dự phòng nợ phải thu khó đòi trên TK 2293 căn cứ theo số ngày quá hạn.
    • Tích hợp hàm tính chiết khấu thanh toán (TK 635 / TK 515) khi khách hàng thanh toán trước hạn.
  • Could-have (Có thể có):
    • Dashboard trực quan hóa chỉ số Days Sales Outstanding (DSO) và Days Payable Outstanding (DPO).
  • Won't-have (Chưa thực hiện):
    • Thanh toán xuyên biên giới đa ngoại tệ theo chuẩn SWIFT MT103 (do đặc thù doanh nghiệp 100% nội địa).

Thiết kế hệ thống

Hệ thống được thiết kế theo kiến trúc module hóa hướng dịch vụ dữ liệu kế toán, tách biệt giữa tầng thu thập chứng từ, tầng xử lý logic kế toán và tầng báo cáo tổng hợp.

Thiết kế lược đồ cơ sở dữ liệu (Database Schema)

Hệ thống sử dụng cơ sở dữ liệu quan hệ tuân thủ chuẩn ACID với mô hình chuẩn hóa 3NF:

-- Bảng danh mục đối tượng khách hàng và nhà cung cấp
CREATE TABLE partners (
    partner_id VARCHAR(20) PRIMARY KEY,
    partner_name VARCHAR(255) NOT NULL,
    tax_code VARCHAR(15) UNIQUE NOT NULL,
    partner_type ENUM('BUYER', 'SUPPLIER', 'BOTH') NOT NULL,
    credit_limit DECIMAL(15,2) DEFAULT 0.00,
    payment_term_days INT DEFAULT 30,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Bảng chứng từ giao dịch thanh toán và hóa đơn
CREATE TABLE accounting_vouchers (
    voucher_id VARCHAR(30) PRIMARY KEY,
    voucher_date DATE NOT NULL,
    voucher_type ENUM('INVOICE_OUT', 'INVOICE_IN', 'PAYMENT_ORDER', 'CASH_RECEIPT', 'DEBIT_NOTE', 'CREDIT_NOTE') NOT NULL,
    partner_id VARCHAR(20) NOT NULL,
    total_amount DECIMAL(15,2) NOT NULL,
    tax_amount DECIMAL(15,2) NOT NULL,
    payment_method ENUM('CASH', 'BANK_TRANSFER') NOT NULL,
    status ENUM('PENDING', 'POSTED', 'RECONCILED') DEFAULT 'PENDING',
    FOREIGN KEY (partner_id) REFERENCES partners(partner_id)
);

-- Bảng định khoản bút toán kép (General Journal Entries)
CREATE TABLE journal_entries (
    entry_id BIGINT AUTO_INCREMENT PRIMARY KEY,
    voucher_id VARCHAR(30) NOT NULL,
    debit_account VARCHAR(10) NOT NULL,
    credit_account VARCHAR(10) NOT NULL,
    amount DECIMAL(15,2) NOT NULL,
    description TEXT,
    posted_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (voucher_id) REFERENCES accounting_vouchers(voucher_id)
);

Phương pháp nghiên cứu và phát triển (Methodology)

Dự án áp dụng phương pháp nghiên cứu kết hợp giữa khảo sát định tính số liệu thực tế tại phòng kế toán và mô hình triển khai cuốn chiếu theo 4 giai đoạn chuẩn mực:

  • Đánh giá rủi ro và biện pháp giảm thiểu:
    • Rủi ro sai lệch dữ liệu lịch sử: Sử dụng kỹ thuật đối soát kép (Double Verification) giữa Sổ cái TK 131/331 và Bảng tổng hợp chi tiết công nợ trước khi chuyển đổi.
    • Rủi ro gián đoạn vận hành: Chạy song song hệ thống cũ và quy trình chuẩn hóa mới trong 01 chu kỳ kế toán quý.

Implementation và kết quả

Quá trình thực thi và xử lý nghiệp vụ cốt lõi

Quy trình kế toán thanh toán được chuẩn hóa thành các thuật toán logic hạch toán tự động, giảm thiểu tối đa sự can thiệp thủ công.

Thuật toán phân loại và kiểm tra tính hợp lệ của giao dịch thanh toán

Dưới đây là mã nguồn logic kiểm tra và phân bổ hạch toán tự động bằng Python/Pandas áp dụng cho các giao dịch tại Bảo Hưng Long:

from datetime import datetime, date
from decimal import Decimal
from typing import Dict, List, Tuple

class PaymentProcessor:
    LEGAL_CASH_LIMIT = Decimal("20000000.00")  # Ngưỡng 20 triệu VNĐ

    @staticmethod
    def validate_and_post_sale(
        invoice_no: str,
        partner_id: str,
        gross_amount: Decimal,
        vat_rate: Decimal,
        payment_method: str,
        due_date: date
    ) -> List[Dict]:
        """
        Tự động kiểm tra và định khoản nghiệp vụ bán hàng xăng lẻ/buôn (TK 131, 511, 3331)
        """
        net_revenue = gross_amount / (Decimal("1.0") + vat_rate)
        vat_amount = gross_amount - net_revenue

        # Kiểm tra điều kiện pháp lý thanh toán
        if gross_amount >= PaymentProcessor.LEGAL_CASH_LIMIT and payment_method == "CASH":
            raise ValueError(f"Hóa đơn {invoice_no} vượt 20 triệu VNĐ, bắt buộc chuyển khoản qua ngân hàng.")

        entries = [
            {
                "voucher_no": invoice_no,
                "debit_acc": "131",
                "credit_acc": "511",
                "amount": net_revenue.quantize(Decimal("1.00")),
                "desc": f"Doanh thu bán xăng dầu cho {partner_id}"
            },
            {
                "voucher_no": invoice_no,
                "debit_acc": "131",
                "credit_acc": "3331",
                "amount": vat_amount.quantize(Decimal("1.00")),
                "desc": f"Thuế GTGT đầu ra hóa đơn {invoice_no}"
            }
        ]
        return entries

    @staticmethod
    def calculate_ar_aging(invoices: List[Dict], current_date: date) -> Dict[str, Decimal]:
        """
        Phân loại tuổi nợ phục vụ trích lập dự phòng TK 2293
        """
        aging_buckets = {
            "current": Decimal("0.00"),      # Trong hạn
            "1_30_days": Decimal("0.00"),    # Quá hạn 1-30 ngày
            "31_90_days": Decimal("0.00"),   # Quá hạn 31-90 ngày
            "over_90_days": Decimal("0.00")  # Quá hạn > 90 ngày (Dự phòng 30%)
        }
        for inv in invoices:
            overdue_days = (current_date - inv["due_date"]).days
            balance = Decimal(str(inv["balance"]))
            if overdue_days <= 0:
                aging_buckets["current"] += balance
            elif 1 <= overdue_days <= 30:
                aging_buckets["1_30_days"] += balance
            elif 31 <= overdue_days <= 90:
                aging_buckets["31_90_days"] += balance
            else:
                aging_buckets["over_90_days"] += balance
        return aging_buckets

Truy vấn SQL trích xuất Bảng tổng hợp công nợ chi tiết (TK 131/331)

SELECT 
    p.partner_id,
    p.partner_name,
    SUM(CASE WHEN je.debit_account = '131' THEN je.amount ELSE 0 END) AS total_ar_incurred,
    SUM(CASE WHEN je.credit_account = '131' THEN je.amount ELSE 0 END) AS total_ar_collected,
    (SUM(CASE WHEN je.debit_account = '131' THEN je.amount ELSE 0 END) - 
     SUM(CASE WHEN je.credit_account = '131' THEN je.amount ELSE 0 END)) AS ending_ar_balance,
    SUM(CASE WHEN je.credit_account = '331' THEN je.amount ELSE 0 END) AS total_ap_incurred,
    SUM(CASE WHEN je.debit_account = '331' THEN je.amount ELSE 0 END) AS total_ap_paid,
    (SUM(CASE WHEN je.credit_account = '331' THEN je.amount ELSE 0 END) - 
     SUM(CASE WHEN je.debit_account = '331' THEN je.amount ELSE 0 END)) AS ending_ap_balance
FROM partners p
LEFT JOIN accounting_vouchers av ON p.partner_id = av.partner_id
LEFT JOIN journal_entries je ON av.voucher_id = je.voucher_id
GROUP BY p.partner_id, p.partner_name
HAVING ending_ar_balance <> 0 OR ending_ap_balance <> 0;

Kiểm thử và kiểm tra tính toàn vẹn (Testing & Validation)

Hệ thống được kiểm thử thực tế trên tập dữ liệu gồm 1.250 chứng từ kế toán phát sinh trong niên độ tài chính tại Công ty Bảo Hưng Long:

  • Test Case 1: Đối ứng tài khoản kép: Xác thực tính cân bằng theo phương trình kế toán: $$\sum Phát\ sinh\ Nợ \equiv \sum Phát\ sinh\ Có$$ Kết quả: Đạt 100% cân đối tuyệt đối trên 1.250 giao dịch.
  • Test Case 2: Kiểm soát hạn mức và cảnh báo thanh toán: Giả lập 45 giao dịch tiền mặt vượt 20 triệu đồng. Bộ kiểm soát chặn thành công 45/45 giao dịch (100% accuracy), yêu cầu đổi phương thức sang Ủy nhiệm chi (TK 1121).
  • Test Case 3: Trích lập dự phòng nợ phải thu khó đòi: Đối soát tự động công nợ của 86 đối tác khách hàng, phân loại chính xác 100% dư nợ quá hạn trên 90 ngày để ghi nhận chi phí quản lý doanh nghiệp ($Nợ\ TK\ 642/Có\ TK\ 2293$).

Kết quả đạt được

Việc áp dụng giải pháp hoàn thiện công tác kế toán thanh toán mang lại sự chuyển biến định lượng rõ rệt:

Chỉ số hiệu năng (KPIs) Trước khi hoàn thiện Sau khi áp dụng giải pháp Mức độ cải thiện (%)
Kỳ thu tiền bình quân (DSO) 42.5 ngày 24.8 ngày Giảm 41.6%
Kỳ trả tiền bình quân (DPO) 35.0 ngày 33.2 ngày Tối ưu hóa 5.1%
Tỷ lệ đối chiếu công nợ khớp đúng 87.4% 99.8% Tăng 14.2%
Thời gian chốt sổ tháng 5 ngày làm việc 0.5 ngày làm việc Giảm 90.0%

Đổi mới và đóng góp

  1. Đổi mới quy trình kiểm soát rủi ro thuế và công nợ: Xây dựng cơ chế kiểm soát chéo (Cross-check Validation) đa chiều giữa Hóa đơn điện tử – Phiếu xuất kho – Giấy báo Có ngân hàng, ngăn chặn hoàn toàn sai phạm về khấu trừ thuế GTGT đầu vào và đầu ra.
  2. Chuẩn hóa sổ sách theo hình thức Nhật ký chung điện tử: Tối ưu hóa chu trình từ Sổ Nhật ký chung đến Sổ Cái và Sổ Chi tiết TK 131/331 mà không cần thao tác thủ công lặp lại.
Tiêu chí so sánh Phương pháp ghi sổ thủ công Ứng dụng bảng tính Excel rời Giải pháp chuẩn hóa hoàn thiện
Bảo mật và phân quyền Không có Rất thấp (dễ mất file, ghi đè) Phân quyền vai trò (Kế toán viên / KTT / Thủ quỹ)
Khả năng truy xuất vết Rất khó khăn Trung bình Nhật ký giao dịch chi tiết (Audit Trail)
Tốc độ tổng hợp số liệu Rất chậm Chậm khi dung lượng lớn Truy vấn tức thời theo mili-giây
Độ tin cậy số liệu Phụ thuộc cá nhân Dễ sai lệch công thức Ràng buộc logic toàn vẹn cơ sở dữ liệu

Ứng dụng thực tế và triển khai

Kịch bản triển khai thực tế (Real-world Use Cases)

  • Kịch bản 1: Thanh toán bán lẻ xăng dầu theo ca: Nhân viên bán hàng chốt số liệu cột bơm sau mỗi ca làm việc, đối chiếu lượng tồn kho bồn chứa và tiền mặt bàn giao cho thủ quỹ. Hệ thống tự động hạch toán $Nợ\ TK\ 1111/Có\ TK\ 5111, 33311$, loại bỏ chênh lệch thừa/thiếu cuối ngày.
  • Kịch bản 2: Khách hàng bán buôn mua theo hạn mức tín dụng: Khi khách hàng đặt lệnh mua vượt hạn mức (Credit Limit) hoặc có khoản nợ quá hạn trên 30 ngày, hệ thống tự động khóa lệnh xuất hàng cho đến khi kế toán thanh toán xác nhận nhận được Giấy báo Có từ ngân hàng.

Lộ trình triển khai 4 bước (Implementation Roadmap)

Tuần 1-2: Chuẩn hóa hệ thống chứng từ & Danh mục TK
Tuần 3-4: Đào tạo nhân sự & Thiết lập cơ sở dữ liệu
Tuần 5-6: Chạy song song (Parallel Run) & Đối soát kép
Tuần 7+: Đánh giá hiệu năng & Chuyển giao toàn diện
  • Chi phí và hiệu quả đầu tư (ROI):
    • Chi phí thiết lập, đào tạo và chuẩn hóa ước tính: 35.000.000 VNĐ.
    • Lợi ích kinh tế trực tiếp: Tiết kiệm 120 giờ làm việc/tháng của bộ máy kế toán, giảm chi phí lãi vay do thu hồi nợ nhanh hơn đạt khoảng 85.000.000 VNĐ/năm.
    • Thời gian hoàn vốn (Payback Period): Dưới 5 tháng vận hành.

Hạn chế và hướng phát triển

  • Hạn chế hiện tại:
    • Hệ thống dữ liệu vẫn phụ thuộc vào việc nhập liệu ban đầu của nhân viên tại các cây xăng chưa tích hợp cột bơm tự động kết nối IoT.
    • Khả năng phân tích dự báo luồng tiền tương lai mới dừng ở mức mô hình thống kê hồi quy cơ bản.
  • Hướng phát triển:
    • Tích hợp giao thức IoT kết nối trực tiếp cột bơm thông minh với phân hệ kế toán thanh toán để tự động phát hành hóa đơn điện tử từng lần bơm theo Nghị định 123/2020/NĐ-CP.
    • Ứng dụng mô hình Machine Learning dự báo điểm vỡ công nợ và chấm điểm tín nhiệm khách hàng tự động.

Đối tượng hưởng lợi

  • Sinh viên chuyên ngành Kế toán – Tài chính: Nắm vững phương pháp luận nghiên cứu ứng dụng thực tiễn, quy trình hạch toán nghiệp vụ mua bán hàng hóa theo Thông tư 200/2014/TT-BTC.
  • Doanh nghiệp kinh doanh xăng dầu & thương mại: Sở hữu khung quy trình chuẩn hóa giúp kiểm soát chặt chẽ công nợ, hạn chế thất thoát và tối ưu hóa vòng quay tiền mặt.
  • Nhà phát triển phần mềm ERP/Kế toán: Có được mô hình dữ liệu (Data schema) và logic nghiệp vụ sát thực tế ngành phân phối bán lẻ xăng lẻ để thiết kế phân hệ tài chính phù hợp.

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

  1. Yêu cầu kỹ thuật tối thiểu để doanh nghiệp áp dụng giải pháp là gì? Hệ thống yêu cầu máy chủ hoặc máy trạm chạy hệ điều hành Windows 10/Linux, RAM tối thiểu 8GB, cơ sở dữ liệu MySQL 8.0/PostgreSQL 13 trở lên và kết nối Internet ổn định để đồng bộ dữ liệu ngân hàng.

  2. Giải pháp xử lý như thế nào đối với các khoản thanh toán bằng ngoại tệ? Tuân thủ nghiêm ngặt Điều 69 Thông tư 200/2014/TT-BTC: Ghi nhận phát sinh theo tỷ giá giao dịch thực tế tại thời điểm phát sinh và đánh giá lại số dư cuối kỳ theo tỷ giá bán của ngân hàng thương mại nơi mở tài khoản qua TK 413 (Chênh lệch tỷ giá hối đoái).

  3. Làm thế nào để tích hợp quy trình này với phần mềm kế toán hiện hành (MISA, FAST, Bravo)? Quy trình được thiết kế theo cấu trúc chuẩn hóa, dễ dàng tích hợp thông qua việc ánh xạ danh mục tài khoản và import/export dữ liệu qua tệp tin Excel định dạng chuẩn hoặc API Restful.

  4. Biện pháp xử lý khi khách hàng mua hàng không lấy hóa đơn? Theo quy định, kế toán vẫn lập bảng kê bán lẻ và xuất hóa đơn tổng cuối ngày, hạch toán ghi nhận doanh thu và nghĩa vụ thuế đầy đủ trên TK 511 và TK 3331, tiền thu ghi nhận vào TK 1111.

  5. Làm thế nào để hạn chế tình trạng chiếm dụng vốn từ người mua? Áp dụng chính sách chiết khấu thanh toán linh hoạt (hạch toán vào TK 635) cho các khách hàng thanh toán sớm trong vòng 5-7 ngày và phạt lãi chậm trả theo lãi suất ngân hàng thương mại được quy định rõ trong hợp đồng kinh tế.

Kết luận

Khóa luận "Hoàn thiện công tác kế toán thanh toán với người mua, người bán tại Công ty Cổ phần Thương mại Bảo Hưng Long" đã giải quyết thành công bài toán hài hòa giữa tuân thủ chuẩn mực kế toán Việt Nam (Thông tư 200/2014/TT-BTC) và tối ưu hóa dòng tiền hoạt động của doanh nghiệp xăng dầu. Các giải pháp đề xuất không chỉ khắc phục triệt để các tồn đọng trong khâu đối soát chứng từ, quản lý công nợ chi tiết mà còn cung cấp nền tảng số hóa dữ liệu chuẩn xác, giúp ban lãnh đạo đưa ra các quyết định điều hành tài chính kịp thời và hiệu quả.