Khi bộ phận công nợ phải trả của một nhà máy tại Thái Lan nhận hóa đơn nhà cung cấp qua email, PDF, giấy hoặc chứng từ điện tử, việc đọc được chữ mới là bước đầu. Hệ thống còn phải xác định hóa đơn có đến hai lần không, nhà cung cấp thuộc mã nào trong ERP, tổng tiền và thuế có nhất quán không, ai xử lý sai lệch và ai được phê duyệt ghi sổ. Chỉ cài OCR có thể làm đầy các ô dữ liệu mà không rút ngắn hàng chờ kiểm tra.
Bài viết này thiết kế chung khâu tiếp nhận hóa đơn nhà cung cấp, trích xuất, kiểm tra, hàng đợi ngoại lệ và cổng ghi sổ ERP. Bài tự động hóa xử lý hóa đơn đã phân tích hiệu quả đầu tư và đối chiếu ba bên; bài OCR đơn đặt hàng tập trung vào việc đọc PO. Ở đây, phạm vi là chất lượng và kiểm soát dữ liệu hóa đơn từ lúc nhận đến trước khi tạo chứng từ công nợ trong ERP.
Đầu ra cần là bản ghi hóa đơn đủ điều kiện ghi sổ
Văn bản OCR không phải chứng từ công nợ. Bản ghi phải liên kết tệp gốc, mã nhà cung cấp, số hóa đơn, ngày, tiền tệ, loại thuế, các dòng hàng, tổng tiền, PO và phiếu nhận hàng nếu áp dụng, kết quả kiểm tra và lịch sử phê duyệt. Đọc đúng số tiền vẫn chưa đủ nếu chưa xác định được đồng tiền hoặc pháp nhân bán hàng. Hãy định nghĩa “số hóa xong” là đã vượt qua các phép kiểm bắt buộc, đóng các ngoại lệ cản trở và được duyệt để ERP tiếp nhận.
Số chứng từ ERP trả về mới chứng minh ghi sổ thành công. Gửi một yêu cầu API không đồng nghĩa đã ghi sổ; timeout có thể che khuất một giao dịch thành công, còn thử lại thiếu kiểm soát có thể tạo giao dịch thứ hai. Lưu tệp gốc mà không ghi đè. Ghi kênh và thời điểm nhận, dấu vân tay tệp, phiên bản công cụ trích xuất, giá trị trước và sau sửa, người sửa và người duyệt. Nhờ vậy có thể giải thích chứng từ gốc ghi gì và doanh nghiệp đã quyết định hạch toán ra sao. Bộ phận thuế và pháp lý tại địa phương cần xác nhận thời hạn lưu trữ.
Gom các kênh tiếp nhận vào một hàng đợi có kiểm soát
Nhà cung cấp có thể gửi đến hộp thư chung, hộp thư cá nhân, qua giấy, cổng thông tin hoặc EDI. Chỉ định điểm tiếp nhận chính thức và chủ trách nhiệm cho từng kênh. Hộp thư cá nhân dễ tạo khoảng trống khi nhân viên nghỉ hoặc chuyển việc. Với bản giấy, ghi người quét và thời điểm quét; quy định lưu bản giấy là vấn đề riêng. Một email có thể kèm hóa đơn, phiếu giao hàng và thông báo thanh toán, vì thế phải phân loại từng tệp trước khi tạo ứng viên hóa đơn. Chưa tạo chứng từ công nợ ở bước này.
Tệp hỏng, thiếu trang, PDF khóa mật khẩu hoặc ảnh quá mờ phải chuyển vào nhánh yêu cầu gửi lại. Dùng hash để tìm bản gửi lại giống hệt; dùng nhà cung cấp, số hóa đơn, ngày và số tiền để gợi ý bản trùng khi tệp được in và quét lại. Chỉ dùng hash sẽ bỏ sót bản quét lại, còn chặn theo số hóa đơn đơn lẻ có thể khóa nhầm giao dịch hợp lệ khi số được tái dùng theo năm. Phân biệt “trùng chắc chắn” với “tương tự cần kiểm tra”. Kiểm tra trùng thêm lần nữa trước khi ghi sổ và dùng mã tham chiếu bên ngoài ổn định khi gọi ERP.
Xác định trường cần trích xuất từ yêu cầu của ERP
Xem màn hình nhập công nợ và đặc tả tích hợp thực tế để phân loại trường bắt buộc, tùy chọn và tính toán. Các trường thường gặp gồm nhà cung cấp, số và ngày hóa đơn, hạn thanh toán, tiền tệ, tiền trước thuế, thuế, tổng tiền, mã hàng, số lượng, đơn giá, số PO và trung tâm chi phí. Cấu hình ERP của từng doanh nghiệp quyết định danh sách thật. Đánh giá công cụ theo độ chính xác từng trường, độ đầy đủ của dòng hàng và khả năng xử lý bảng nhiều trang, không chỉ theo một tỷ lệ nhận dạng ký tự.
Tài liệu Amazon Textract mô tả AnalyzeExpense trả về các trường hóa đơn/biên lai, dòng hàng, vị trí trên trang và độ tin cậy. Google Cloud Document AI công bố Invoice Parser cho phần đầu và dòng hàng. Các mô tả này không chứng minh công cụ phù hợp ngay với biểu mẫu tiếng Thái, tiếng Nhật hoặc nhiều ngôn ngữ của nhà cung cấp cụ thể. Danh sách ngôn ngữ Google công bố gắn với processor và phiên bản; cần đối chiếu tài liệu chính thức và thử bằng chứng từ thật trước khi khẳng định hỗ trợ. Lớp chuẩn hóa vẫn phải chuyển tên, ngày, số tiền và tiền tệ thành mã và định dạng ERP cần.
“ABC Co., Ltd.” và “ABC COMPANY LIMITED” có thể cùng một nhà cung cấp, nhưng độ giống tên không đủ để chọn pháp nhân. Đối chiếu mã số thuế, địa chỉ và dữ liệu master đã được phê duyệt. Nếu có nhiều ứng viên, đưa vào hàng ngoại lệ. Chỉ lưu tên thay thế sau khi được duyệt; tách quyền sửa master khỏi quyền duyệt hóa đơn. Lưu văn bản gốc, giá trị chuẩn hóa đề xuất, độ tin cậy và tọa độ trên trang để người kiểm có thể nhìn lại bằng chứng.
Tổng tiền đúng không thay thế được các dòng hàng
Hóa đơn nhà máy có thể trải nhiều trang với vật tư, số lượng, đơn giá, giảm giá, vận chuyển và thuế. Nếu mua hàng phải phân bổ từng dòng vào PO, chỉ đọc tổng tiền không hoàn thành công việc. Đo “dòng đã đọc” và “dòng đã ghép PO” thành hai chỉ số. Thử mô tả dài xuống dòng, bảng nối trang, khoản giảm trừ âm và đơn vị số lượng khác nhau. Cùng một “1,250.00” có thể là số lượng, đơn giá hoặc thành tiền tùy cột. Cho người kiểm thấy vị trí gốc được đánh dấu thay vì chỉ thấy một con số.
Kiểm tra bốn lớp sau OCR
Độ tin cậy của OCR là tín hiệu phân luồng, không phải bằng chứng nghiệp vụ đúng. Văn bản có thể rõ mà tên người mua sai. Chia các phép kiểm như sau:
| Lớp | Câu hỏi | Cách xử lý khi không đạt |
|---|---|---|
| Tài liệu | Tệp đọc được, đủ trang, đúng loại? | Xin tệp hoặc bản quét mới |
| Trường | Đủ dữ liệu bắt buộc, định dạng đúng? | Xem bản gốc và sửa |
| Số học | Dòng hàng, thuế và tổng tiền giải thích được? | Xem làm tròn, giảm giá, vận chuyển |
| Nghiệp vụ | Nhà cung cấp, PO, nhận hàng, phê duyệt, trùng lặp đạt? | Giao nhóm chịu trách nhiệm |
Không áp một thuế suất cố định để tính lại mọi hóa đơn. Loại thuế, cách làm tròn và thứ tự giảm giá thay đổi theo giao dịch. Trước hết giải thích chênh lệch; chỉ đặt ngưỡng tự chấp nhận khi kế toán phê duyệt quy tắc. Kiểm trạng thái nhà cung cấp, PO, lượng đã nhận, tài khoản và hạn mức duyệt. Hóa đơn dịch vụ không PO hoặc khoản ứng trước cần tuyến riêng, không bị ép qua đối chiếu ba bên của vật tư. Số tài khoản ngân hàng thay đổi in trên hóa đơn không được tự sửa master mà phải qua xác minh riêng.
Hàng ngoại lệ phải giúp người phụ trách giải quyết việc
Mã lý do “OCR lỗi” quá chung. Tách thiếu trang, thiếu trường, chưa rõ nhà cung cấp, nghi trùng, lệch số học, PO không khớp, chưa nhận hàng, chờ duyệt và ERP từ chối. Mỗi ngoại lệ cần ID hóa đơn, quy tắc thất bại, vùng chứng từ gốc, giá trị đề xuất, vai trò phụ trách, hạn xử lý, trao đổi và lịch sử sửa. Sau khi sửa, chạy lại các quy tắc số học và nghiệp vụ liên quan. Không cho phép bỏ qua mọi kiểm tra chỉ vì một ô đã được người dùng sửa.
Giao nhận diện nhà cung cấp cho mua hàng, lượng nhận cho kho, loại thuế cho kế toán, lỗi API ERP cho IT; đồng thời giữ một người chịu trách nhiệm tổng thể ở công nợ. Trạng thái “chờ nhà cung cấp” phải kèm ngày đã yêu cầu gửi lại và số ngày chờ. Ưu tiên theo hạn trả, lịch khóa sổ, ảnh hưởng sản xuất và rủi ro trùng, không chỉ theo số tiền. Thông báo cần nói rõ quy tắc nào không đạt và bằng chứng nào có thể giải quyết.
Tỷ lệ ngoại lệ là tín hiệu quy trình, không chỉ là điểm số mô hình. Nguyên nhân có thể nằm ở mẫu hóa đơn, PO không ghi trên chứng từ, nhập kho chậm, thiếu tên thay thế trong master hoặc ngưỡng sai lệch chưa được duyệt. Phân tích theo lý do, nhà cung cấp và bộ phận mua hàng. Đừng nới ngưỡng chỉ để biểu đồ đẹp hơn; theo dõi cả điều chỉnh sau ghi sổ, hoàn trả thanh toán và tuổi của các vụ chưa đóng.
Đặt ba cổng kiểm soát ERP: trước, trong và sau ghi sổ
Trước khi gửi, xác nhận liên kết tệp gốc, các trường bắt buộc, trùng lặp, duyệt, tài khoản, thuế và PO/nhận hàng liên quan. Chuyển dữ liệu thành mã master và định dạng hợp lệ rồi khóa phiên bản sẽ gửi. Trong khi gửi, sử dụng ID hóa đơn bên ngoài ổn định nếu ERP hỗ trợ. Nếu API timeout, truy vấn ERP bằng ID đó trước khi thử lại. Nếu ERP không có idempotency gốc, hệ thống tích hợp phải lưu trạng thái gửi bền vững và có bước đối soát.
Sau khi gửi, lưu số chứng từ ERP và trạng thái cuối. Nếu ERP xử lý bất đồng bộ, theo dõi cho đến kết quả cuối. Đưa thông báo từ chối về hàng ngoại lệ với lý do có thể xử lý. Hủy và ghi sổ lại phải liên kết với chứng từ ban đầu. Chỉ số cần là “đã ghi đúng trong ERP”, không phải “đã truyền sang ERP”.
Phân biệt e-Tax Invoice của Thái Lan với OCR
Nhận PDF nhà cung cấp rồi đọc bằng OCR tự nó không tạo hoặc xác thực e-Tax Invoice. FAQ của ETDA mô tả chứng từ thuế điện tử có chữ ký số để giao cho người mua và cho biết dữ liệu gửi Cục Thuế Thái Lan phải ở định dạng XML quy định. Cục Thuế duy trì cổng thông tin e-Tax. Đó là yêu cầu đối với chứng từ thuế; OCR là phương pháp nhập dữ liệu.
Khi chứng từ nhận được là e-Tax Invoice, bộ phận kế toán và thuế phải quyết định đường kiểm tra. ETDA giới thiệu TEDA Web Validation để kiểm các yếu tố như chữ ký, dấu thời gian và cấu trúc trong định dạng được hỗ trợ gồm PDF/PDF-A-3 và XML. Xác thực chữ ký và độ đúng trường OCR trả lời hai câu hỏi khác nhau. Xác định vị trí kiểm chứng, lưu bằng chứng và yêu cầu của Cục Thuế trong quy trình. Bài viết này không thay thế kết luận thuế cho một giao dịch cụ thể.
Nếu trụ sở ở nước khác cần truy cập, xác định nơi lưu bản gốc và dữ liệu trích xuất, quyền xem, cũng như cách xuất lịch sử chỉnh sửa. Khi chọn dịch vụ đám mây, kiểm khu vực khả dụng, quyền truy cập, log, xóa dữ liệu và điều khoản dùng dữ liệu huấn luyện trong hợp đồng và tài liệu sản phẩm thực tế.
PoC phải đo đến số chứng từ ERP
Bộ thử nghiệm nên đại diện cho nhà cung cấp, kênh nhận, ngôn ngữ, số trang, loại giao dịch và chất lượng tài liệu thực. Đưa vào hóa đơn vật tư có PO, chi phí không PO, giảm giá, vận chuyển, gửi lại, giấy báo có và bản quét khó đọc. Kế toán cùng mua hàng xác lập dữ liệu đúng. Nếu chứng từ gốc thật sự mơ hồ, ghi nhận sự mơ hồ thay vì tự tạo đáp án. Đo riêng phân loại tài liệu, độ đúng trường bắt buộc, độ đầy đủ dòng hàng, xác định nhà cung cấp, tỷ lệ ngoại lệ, thời gian giải quyết, tỷ lệ ghi ERP và số điều chỉnh sau ghi.
Ví dụ sau chỉ là giả định tính toán, không phải số liệu thực tế: Nhà máy nhận 1.000 hóa đơn/tháng. Có 850 hóa đơn qua kiểm lần đầu và 150 vào hàng ngoại lệ. Nhân viên giải quyết 100 trong tháng, còn 50. Tỷ lệ qua lần đầu là 85%; 850 + 100 = 950 hóa đơn, tức 95%, tới cổng ghi sổ trong tháng; 5% còn mở. Số chứng từ được ERP ghi hoàn toàn không có người chạm vào là chỉ số riêng, không thể tự coi là 850 vì vẫn có thể dừng ở duyệt hoặc bị ERP từ chối.
Nếu mô hình trích xuất tốt hơn giúp 900 hóa đơn qua kiểm lần đầu nhưng 200 bị chặn ở ERP do master nhà cung cấp chưa hoàn chỉnh, kết quả toàn tuyến chưa chắc tốt hơn. Đặt điều kiện đạt PoC ở việc theo dõi được đến số chứng từ ERP cuối cùng dưới các điều kiện chất lượng và phê duyệt đã thỏa thuận. Luôn nêu mẫu số khi báo cáo “tỷ lệ tự động”.
Lưu kết quả thử nghiệm ở cấp từng hóa đơn để thấy nguyên nhân dừng. Nếu hai mươi hóa đơn của cùng một nhà cung cấp đều bị đọc sai số, nguyên nhân có thể là quy tắc bố cục hoặc chất lượng bản gốc. Nếu số đã đọc đúng nhưng không tìm được mã nhà cung cấp ERP, vấn đề là master. Gộp cả hai vào một tỷ lệ thất bại sẽ che khuất quyết định đầu tư. Với cùng ID hóa đơn, ghi loại tài liệu, giá trị trích xuất, giá trị đúng đã thống nhất, quy tắc thất bại, chỉnh sửa của người dùng và phản hồi ERP. Nhờ đó tách được việc cấu hình sản phẩm khỏi thay đổi vận hành của mua hàng hoặc kế toán.
Đo cả thời gian con người giải quyết ngoại lệ. OCR có thể hoàn tất trong vài giây, nhưng yêu cầu nhà cung cấp gửi lại chứng từ có thể chờ ba ngày và làm chậm khóa sổ. Ngược lại, tô sáng dòng gốc có thể rút ngắn thời gian xem xét dù số ngoại lệ không đổi. Tách thời gian đến kiểm tra đầu tiên, thời gian đến giao người phụ trách, thời gian thao tác sửa thực tế, thời gian chờ phản hồi bên ngoài và thời gian đến đăng ký cuối trong ERP. Các khoảng trễ này cần biện pháp khác nhau.
Nêu rõ loại tài liệu bị loại khỏi PoC. Thử nghiệm không có hóa đơn viết tay hoặc nhiều ngôn ngữ không thể chứng minh phù hợp cho mọi nhà cung cấp. Nếu kết quả tốt chỉ từ một bố cục ổn định, giới hạn triển khai đầu tiên trong phạm vi đó. Nếu bộ thử cố ý chọn nhiều chứng từ khó, giải thích tỷ trọng khác với lượng nhận hàng tháng ra sao. Giữ bản gốc và bảng đánh giá để so sánh mô hình hoặc dịch vụ sau bằng cùng điều kiện.
Triển khai theo nhóm nhà cung cấp và luồng giao dịch
Bắt đầu với nhóm có đủ số lượng, mẫu chứng từ tương đối ổn định và master ERP dùng được. Kiểm soát kênh nhận, bản gốc và trùng lặp trước. Tiếp theo triển khai trích xuất phần đầu với người kiểm. Khi đã thấy các lý do ngoại lệ, mở rộng sang dòng hàng, PO, nhận hàng, duyệt và ghi ERP. Thống nhất người duyệt tên thay thế của nhà cung cấp, ngưỡng chênh lệch, hóa đơn không PO, loại thuế, hủy chứng từ và ngoại lệ cuối tháng trước khi lập trình thành quy tắc.
Định nghĩa các trạng thái: đã nhận, đã trích xuất, đang kiểm, chờ nhà cung cấp, chờ mua hàng, chờ duyệt, sẵn sàng ghi, đã ghi và đã hủy. Mỗi trạng thái cần điều kiện vào/ra, người phụ trách, hạn và quyền thao tác. Chuẩn bị mẫu hóa đơn, dữ liệu master, PO, phiếu nhận, vụ trùng từng gặp và bản đồ trường ERP cho PoC. Kiểm tra bảo mật và lưu trữ trước khi đưa chứng từ thật cho nhà cung cấp công nghệ. So sánh sản phẩm bằng đầu ra dòng hàng, độ tin cậy và tọa độ gốc, xuất nhật ký, chứng từ nhiều ngôn ngữ, phân luồng ngoại lệ và thử lại ERP an toàn, không chỉ giá OCR mỗi trang.
Sau triển khai, xem các ngoại lệ hàng đầu mỗi tuần và điều chỉnh sau ghi sổ mỗi tháng. Sửa quy tắc tiếp nhận, master, thiết lập trích xuất hoặc đối chiếu theo nguyên nhân. Chạy lại bộ chứng từ đại diện khi thay mô hình hoặc quy tắc. Kiểm duyệt việc sửa của nhân viên trước khi dùng làm dữ liệu huấn luyện.
Giao người chịu trách nhiệm cho từng trạng thái
Nếu người nhận hóa đơn cũng phải xử lý mọi lỗi, công việc sẽ dồn vào một hộp thư công nợ. Giao nhận diện nhà cung cấp chưa rõ cho mua hàng, dữ liệu nhập kho thiếu cho kho, loại thuế cho kế toán và ERP từ chối cho IT. Vẫn cần một người chịu trách nhiệm cuối cùng về bút toán phải trả; khi hai bộ phận liên quan, quy định rõ ai hành động tiếp. Trạng thái “đang xử lý” kéo dài vô hạn làm mất khả năng phân tích. Với mỗi trạng thái, ghi điều kiện vào/ra, vai trò được thao tác, hạn và nơi trả về. Trường hợp cần đẩy nhanh vào cuối tháng phải có phê duyệt ngoại lệ được lưu riêng với phê duyệt thông thường.
Chuẩn bị bộ dữ liệu tối thiểu cho PoC
Thu thập mẫu gốc của nhà cung cấp mục tiêu, bản trích master nhà cung cấp, PO và phiếu nhận tương ứng, các vụ trùng hoặc bị từ chối trước đây, cùng bản đồ trường AP trong ERP. Đưa cả vụ nhân viên từng phải giải quyết qua điện thoại hoặc email, không chỉ vụ đẹp. Thiếu một ID chung nối bản gốc với chứng từ ERP thì không đo được ghi sổ thành công. Trước khi đưa chứng từ thật vào thử nghiệm với bên thứ ba, kiểm mục đích sử dụng được phép, vùng lưu, quyền truy cập và cách xóa. Che số tài khoản hoặc mã số thuế đôi khi làm thử nghiệm không còn thực tế; dùng chứng từ giả để thử giao diện và môi trường kiểm soát chặt để đo trên chứng từ thật khi cần.
Hỏi nhà cung cấp công nghệ nhiều hơn “có đọc được hóa đơn không?”
Hỏi sản phẩm trả dòng hàng nhiều trang thế nào, có độ tin cậy từng trường và tọa độ gốc không, quản lý quy tắc sửa theo nhà cung cấp và xuất lịch sử sửa ra sao, xử lý mẫu tiếng Thái, Anh, Nhật thực tế như thế nào. Trình diễn bằng chứng từ khó của công ty và yêu cầu người kiểm lần ngược giá trị đề xuất về bản gốc. Hỏi cách gửi lại ERP tránh trùng, cách gán người và hạn cho ngoại lệ, cách biến lỗi API thành hướng xử lý dễ hiểu. Trong báo giá, tách phí trích xuất mỗi trang khỏi tích hợp kênh, lưu trữ, dọn master, hàng ngoại lệ, giao diện ERP, kiểm thử và hỗ trợ. Ngoại lệ cao lúc đầu tạo công việc của người mà giá OCR mỗi trang không thể hiện.
Kết nối ranh giới với mua hàng và nhập kho
Số hóa hóa đơn xử lý tài liệu nhận từ nhà cung cấp. Tạo và duyệt PO, OCR PO và nhập kho là các quy trình khác nhưng phải dùng khóa đối chiếu chung. Đọc đúng số PO trên hóa đơn chưa đủ nếu PO trong ERP đã đóng, dùng tiền tệ khác hoặc chưa ghi phiếu nhận. Cổng ghi sổ phải chặn và hiện rõ khóa nào xung đột cùng bộ phận sở hữu dữ liệu cần sửa, thay vì bắt người dùng tự dò một danh sách mơ hồ. Để xử lý PO ở đầu nguồn, xem OCR đơn đặt hàng. Để xem hiệu quả đầu tư và thiết kế đối chiếu ba bên tổng thể, xem tự động hóa xử lý hóa đơn. Phần này nằm giữa hai ranh giới: chuyển hóa đơn đã nhận thành dữ liệu ERP đáng tin cậy.
Câu hỏi thường gặp khi triển khai
Nếu nhà cung cấp gửi PDF, chỉ cần bỏ quét giấy có đủ không?
PDF giúp giảm thất lạc và quét lại nhưng vẫn là tài liệu để người đọc. Nó không nhất thiết có mã nhà cung cấp ERP hay phân loại tài khoản, và cùng một PDF có thể được gửi hai lần. Kiểm soát kênh, phát hiện trùng, trích xuất, kiểm tra nghiệp vụ và lịch sử duyệt vẫn cần thiết. Nếu nhà cung cấp gửi dữ liệu có cấu trúc, cân nhắc nhận trực tiếp thay OCR nhưng vẫn kiểm tính xác thực và sự phù hợp với giao dịch.
Có thể tự ghi sổ các trường có độ tin cậy cao không?
Có thể tự chấp nhận trường theo quy tắc đã duyệt, nhưng điểm tin cậy của mô hình không phải quyền ghi sổ. Sai một chữ số trong số hóa đơn có thể làm kiểm trùng thất bại dù điểm cao. Ngược lại, sai nhỏ trong địa chỉ có thể xử lý được nếu pháp nhân và mã ERP được xác minh từ nguồn khác. Đặt điều kiện xem lại theo hậu quả nghiệp vụ của từng lỗi. Dùng độ tin cậy để hướng sự chú ý của người kiểm, không dùng một ngưỡng chung cho mọi trường.
ERP không có API thì còn tự động hóa được không?
Chức năng nhập CSV hoặc tệp của ERP vẫn có thể là đường tích hợp. Không coi tạo tệp là thành công: kiểm kết quả nhập và trả số chứng từ ERP hoặc lỗi về bản ghi nguồn. Với nhập thủ công, lưu phiên bản tệp, người thao tác và thời gian. Tự động bấm màn hình có thể thực hiện trong một số môi trường nhưng dễ hỏng khi màn hình đổi hoặc dừng giữa chừng. Thiết kế chống trùng và đối soát kết quả trước. Cổng trước và sau ghi sổ vẫn cần thiết với mọi phương thức truyền.
Có nên buộc mọi nhà cung cấp dùng một mẫu?
Một bố cục chung cho tất cả có thể không thực tế. Quy tắc nhỏ như luôn ghi số PO, đánh dấu email gửi lại, tách hóa đơn và phiếu giao hàng thành tệp riêng có thể giảm ngoại lệ nhiều hơn đổi mô hình. Phân tích nguyên nhân của nhà cung cấp chính rồi thương lượng thay đổi ít tốn công. Nếu đổi mẫu, quy định thời gian dùng song song mẫu cũ và mới, thử cả hai để không bỏ sót chứng từ trong giai đoạn chuyển.
Kế toán hay IT nên sở hữu vận hành?
Kế toán thường sở hữu quy tắc nghiệp vụ và bút toán cuối; IT lo kết nối, giám sát, quyền và xử lý sự cố. Vai trò của mua hàng hoặc trung tâm dịch vụ chung tùy tổ chức. Ghi rõ ai chẩn đoán OCR đọc sai, master cũ hay ERP từ chối; ai sửa; ai cho phép gửi lại. Họp ngoại lệ với kế toán, mua hàng, kho và IT để lỗi đầu nguồn không bị gắn nhầm thành lỗi OCR.
Cần giám sát gì mỗi ngày?
Theo dõi số tài liệu đã nhận, chưa phân loại, qua kiểm, chưa giải quyết theo nguyên nhân, phê duyệt chờ lâu nhất, tồn chờ ghi và lỗi ERP. Đối chiếu log hộp thư hoặc cổng nhận với hàng ứng viên hóa đơn: tài liệu đã nhận mà vắng khỏi mọi hàng là rủi ro lớn. Cuối tháng, giải thích được số nhận là đã ghi, đã hủy hay còn mở. Khi OCR hoặc ERP ngừng, vẫn giữ bản gốc an toàn, duy trì ID và kiểm từng bút toán thủ công hoặc gửi lại với ERP trước khi trở lại vận hành thường.
Kiểm soát thay đổi mô hình trích xuất thế nào?
Đổi bố cục có thể khiến trường trước đây đọc đúng nay lấy nhầm cột. Thử thay đổi trên hóa đơn bình thường và khó, gồm giảm giá, nhiều trang và số hóa đơn gần giống. So sánh độ đúng từng trường, lý do ngoại lệ và tỷ lệ qua cổng ERP trước sau. Nếu một nhà cung cấp tốt lên còn nhà khác xấu đi, giới hạn triển khai theo nhà cung cấp. Ghi thời điểm áp dụng, mẫu ảnh hưởng, người chịu trách nhiệm, người duyệt và cách quay lại. Không âm thầm sửa chứng từ ERP đã duyệt và ghi sổ vì mô hình được nâng cấp; phải dùng thủ tục điều chỉnh có dấu vết của ERP.
Chuẩn bị gì cho cuộc trao đổi đầu tiên?
Không cần toàn bộ kho hóa đơn của mọi nhà cung cấp. Mang ba đến năm mẫu chính đã che thông tin nhạy cảm, mỗi mẫu có một ví dụ thông thường và một ví dụ khó; số lượng tháng, kênh nhận, màn hình AP ERP, cách đối chiếu PO/nhập kho và lý do bị trả thường gặp. Nếu chưa thống kê tháng, đếm lượng và thời gian xử lý một tuần gần đây. Giữ nguyên bố cục khi che tên, tài khoản, người và giá. Khi che dữ liệu làm sai lệch câu hỏi về độ chính xác, thử trên chứng từ thật trong môi trường hạn chế quyền. Quyết định chung đầu tiên là điều kiện nào khiến kế toán yên tâm ghi sổ, không chỉ là OCR đọc được bao nhiêu ký tự.
Tóm tắt
Số hóa hóa đơn đầu vào thành công khi tài liệu nhà cung cấp trở thành một bản ghi ERP được kiểm soát, kiểm chứng và ghi đúng một lần. Hợp nhất kênh nhận, giữ bản gốc, kiểm tài liệu, trường, số học và nghiệp vụ; đóng ngoại lệ với người chịu trách nhiệm rõ ràng; xác nhận số chứng từ ERP. Kiểm tính xác thực e-Tax của Thái Lan như một bước riêng với OCR.
TOMAS TECH có thể giúp nhà máy tại Thái Lan đối chiếu hóa đơn mẫu với yêu cầu ERP, chọn nhóm nhà cung cấp đầu tiên và thiết kế hàng ngoại lệ cùng cổng ghi sổ. Liên hệ với chúng tôi bằng mẫu đã ẩn thông tin nhạy cảm, số lượng hàng tháng và những lý do công việc thường dừng, để xác định phạm vi thử nghiệm cụ thể.
