Cách triển khai tự động hóa hóa đơn mà vẫn kiểm soát việc phê duyệt

Triển khai tự động hóa hóa đơn cần giúp việc ghi nhận, rà soát và truy vết hóa đơn trở nên dễ hơn. Trước hết, hãy quyết định hóa đơn nào có thể đi theo quy trình đã định, trường hợp nào cần con người xử lý và ai có quyền cho phép bước tiếp theo. Sau đó mới đến việc chọn công cụ trích xuất.

Hóa đơn đọc được vẫn phải qua kiểm tra tính hợp lệ. Hóa đơn hợp lệ vẫn cần được phê duyệt. Hóa đơn đã được phê duyệt vẫn có thể chưa đủ điều kiện thanh toán. Hãy thể hiện rõ từng trạng thái khi thiết kế quy trình.

Bài viết hướng dẫn bộ phận tài chính giới hạn phạm vi một đợt thí điểm, kiểm thử các ca khó và quyết định có nên mở rộng hay không. Các ví dụ đều là giả định, minh họa thiết kế vận hành đề xuất. Chúng không đại diện cho kết quả của khách hàng Qonnex hay cam kết tiết kiệm.

Xác định ranh giới triển khai tự động hóa hóa đơn

Bắt đầu với một nhóm hóa đơn và một hệ thống đích. “Toàn bộ khoản phải trả” còn quá rộng. Một phạm vi có thể kiểm thử là “hóa đơn nhà cung cấp gửi qua hộp thư chung của bộ phận công nợ phải trả (AP) cho một đơn vị kinh doanh, được ghi dưới dạng bản nháp trong hệ thống kế toán hiện có”.

Ghi rõ điểm bắt đầu và kết thúc. Quy trình bắt đầu khi nhận email, chấp nhận tệp đính kèm hay khi nhà cung cấp tải tệp lên? Quy trình kết thúc khi hóa đơn được ghi nhận, được duyệt hay khi lập đề xuất thanh toán? Chọn một mốc cho mỗi đầu.

Với đợt thí điểm đầu tiên, một điểm kết thúc phù hợp là hóa đơn được ghi nhận chính xác, đã phê duyệt và vẫn tuân theo kiểm soát thanh toán hiện hành. Việc cho phép chi tiền nằm ngoài thí điểm trừ khi tài chính chủ động đưa vào phạm vi và phê duyệt riêng.

Ghi các trường hợp loại trừ chi tiết như luồng thông thường. Chứng từ ghi giảm, hóa đơn đang tranh chấp, nhà cung cấp mới, thay đổi thông tin ngân hàng, ngoại tệ và hóa đơn không có đơn đặt hàng có thể cần xử lý riêng. Hãy đưa các trường hợp ngoài phạm vi vào hàng đợi có người phụ trách để tránh chúng bị bỏ quên trong hộp thư.

Nếu nhóm vẫn đang tìm hiểu thời gian bị tiêu tốn ở đâu, hướng dẫn của Qonnex về chi phí công việc thủ công giúp chẩn đoán ở phạm vi rộng hơn. Ở đây, hãy chọn một luồng hóa đơn và ghi rõ từng quyết định của luồng đó.

Quan sát công việc trước khi thiết kế quy trình mới

Theo dõi một mẫu nhỏ nhưng có chủ đích đa dạng từ lúc tiếp nhận đến điểm kết thúc hiện tại. Chọn cả hóa đơn thông thường và các ca khó. Đề nghị nhân viên công nợ phải trả cho xem cách xử lý khi thiếu mã tham chiếu của nhà cung cấp hoặc khi người duyệt vắng mặt.

Ở mỗi bước bàn giao, ghi lại thông tin được dùng, hệ thống được tra cứu, quyết định được đưa ra và bằng chứng để lại. Chú ý cả công việc ngoài ứng dụng kế toán, như bảng tính mã đơn đặt hàng, email xin chứng từ nhận hàng hoặc tin nhắn duyệt chênh lệch giá.

Những bước bên ngoài này cũng cần được đưa vào thiết kế. Nếu bỏ qua, quy trình mới có thể tự động hóa màn hình nhập liệu nhưng vẫn giữ nguyên công việc tra soát thủ công phía sau.

Lập bảng ghi nhận đầu vào ngắn gọn:

Đây là đặc tả vận hành để người xử lý ngoại lệ tiếp theo có thể đọc và làm theo. Việc chọn phần mềm là một quyết định riêng.

Lập đường cơ sở tách thời gian thao tác khỏi thời gian chờ

Đo riêng thời gian nhân viên trực tiếp xử lý và tổng thời gian của chu trình. Mười phút thao tác rải trong ba ngày là vấn đề khác với ba giờ sửa lỗi liên tục. Trích xuất nhanh hơn có thể giảm thời gian thao tác mà không rút ngắn được thời gian chờ chứng từ nhận hàng bị thiếu.

Cùng tài chính chọn khoảng thời gian quan sát có tính đại diện. Ghi nhận cơ cấu loại hóa đơn, khối lượng, tồn đọng bất thường và các thay đổi quy trình đã lên kế hoạch. Giữ dấu thời gian gốc và phương pháp lấy mẫu để tính lại theo cùng cách sau thí điểm.

Các chỉ số hữu ích gồm thời gian trực tiếp xử lý mỗi hóa đơn, thời gian đến khi phê duyệt, số hóa đơn bị trả lại để sửa, thời gian tồn đọng của ngoại lệ chưa xử lý và số bản ghi đích cần sửa. Định nghĩa tử số và mẫu số cho mọi tỷ lệ. Báo cả số lượng tuyệt đối và tỷ lệ phần trăm để thấy thay đổi về khối lượng.

Không quy mọi phút tiết kiệm thành khoản giảm chi phí lương. Năng lực được giải phóng, giờ làm thêm tránh được và chi phí vận hành đã cắt giảm là những kết quả khác nhau. Người phụ trách tài chính cần quyết định kết quả nào có thể ghi nhận và cần bằng chứng gì.

Hướng dẫn về đường cơ sở tiết kiệm giải thích những nội dung cần thống nhất khi đo. Trong thí điểm này, đính kèm định nghĩa thực tế và nguồn của các chỉ số vào đặc tả quy trình. Dùng số liệu của chính doanh nghiệp làm mốc, thay vì dùng chuẩn tham khảo của nhà cung cấp.

Tách trích xuất, kiểm tra, phê duyệt và thanh toán

Trích xuất chuyển thông tin từ chứng từ nhận được thành các giá trị đề xuất. Kiểm tra đối chiếu giá trị với quy tắc nghiệp vụ và bản ghi có sẵn. Phê duyệt ghi lại quyết định của người có thẩm quyền. Cho phép chi tiền là quyết định để tiền được chuyển theo quy trình thanh toán của doanh nghiệp.

Các chức năng này có thể nằm trong những ứng dụng kết nối với nhau và vẫn cần được tách biệt trong thiết kế. Ví dụ, tài liệu Invoice capture của Microsoft mô tả cách tạo hóa đơn nhà cung cấp từ ảnh số và phân riêng vai trò cấu hình với vai trò rà soát. Đây là ví dụ về một nền tảng. Cần xác minh riêng Qonnex có bộ kết nối sẵn cho sản phẩm này hay không.

Với mỗi trường được trích xuất, xác định nơi ghi và cách kiểm tra. Ngày hóa đơn cần quy tắc về ngày. Mã tham chiếu nhà cung cấp cần quy tắc định danh. Số tiền cần đơn vị tiền tệ và quy tắc đối chiếu tổng tiền. Giá trị trông hợp lý vẫn cần qua kiểm tra nghiệp vụ tương ứng.

Giữ liên kết giữa dữ liệu đề xuất và chứng từ gốc. Người rà soát cần thấy tài liệu đã nhận và lý do một giá trị bị sửa. Quy định dữ liệu nào được lưu làm bằng chứng kiểm toán và thông tin nhạy cảm nào cần loại khỏi nhật ký.

Chặn thay đổi trên hóa đơn tự động cập nhật thông tin thanh toán của nhà cung cấp. Duy trì quy trình được cấp phép riêng để sửa dữ liệu gốc của nhà cung cấp. Trong thí điểm, chuyển sai lệch đó cho người phụ trách để xử lý theo quy trình.

Thiết kế luồng ngoại lệ trước khi tối ưu luồng thông thường

Mỗi ngoại lệ cần bốn yếu tố: lý do rõ ràng, người chịu trách nhiệm, hành động có thể thực hiện và cách quay lại quy trình. Nhãn “cần rà soát” chưa đủ rõ để xử lý ở quy mô lớn.

Giả sử hóa đơn thiếu mã đơn đặt hàng, bước tiếp theo có thể là xin mã từ bộ phận mua hàng. Nếu chưa nhận diện được nhà cung cấp, có thể cần kiểm tra xem đã có hồ sơ nhà cung cấp được phê duyệt hay chưa. Với cả hai trường hợp, tránh điền dữ liệu không có căn cứ chỉ để quy trình chạy tiếp.

Chỉ định người phụ trách thay thế và lịch rà soát hàng đợi. Quy định cách chuyển cấp khi mục tồn đọng quá lâu và cách truy câu hỏi của nhà cung cấp về đúng bản ghi hóa đơn. Hàng đợi chỉ có tác dụng kiểm soát khi có người biết trong đó đang có gì và sẽ xử lý tiếp ra sao.

Tài liệu của Microsoft về không gian làm việc Invoice capture đưa ra ví dụ cụ thể về cách lỗi và cảnh báo dẫn đến bước rà soát và sửa thủ công. Cấu hình của bạn có thể khác. Hãy kiểm tra nhóm có thể thấy và xử lý lại các mục còn tồn đọng hay không.

Quản lý ma trận thẩm quyền bên ngoài mô hình trích xuất

Tài chính cần phê duyệt quy tắc chuyển hồ sơ trước khi thí điểm. Ghi rõ vai trò nào được duyệt từng loại hóa đơn, cách chỉ định người thay, việc cần làm sau khi từ chối và ai được sửa quy tắc.

Độ tin cậy của mô hình khi đọc tên nhà cung cấp không tạo ra thẩm quyền phê duyệt khoản chi. Người kiểm thử trích xuất cũng không nên tự đặt ngưỡng phê duyệt tài chính chỉ vì phần mềm yêu cầu nhập một con số.

Tài liệu phê duyệt hóa đơn của Oracle minh họa quy trình lập danh sách người duyệt dựa trên các quy tắc đã cấu hình. Các giá trị mặc định công bố chỉ áp dụng cho sản phẩm đó. Doanh nghiệp cần dùng chính sách phê duyệt của mình.

Lưu ma trận thẩm quyền chi tiết trong tài liệu hoặc hệ thống có kiểm soát do tài chính quản lý. Đặc tả triển khai cần tham chiếu ma trận, ghi phiên bản áp dụng và nêu người có quyền phê duyệt thay đổi. Duy trì phân tách nhiệm vụ theo thiết kế kiểm soát của tổ chức.

Kiểm thử một nhóm nhỏ gồm các tình huống khó

Một buổi trình diễn thành công với một hóa đơn đầy đủ chưa chứng minh quy trình sẵn sàng vận hành. Hãy lập bộ ca kiểm thử gồm những tình huống làm quy trình thật bị tắc. Dùng tài liệu đã được cấp phép hoặc bản ghi giả lập. Dữ liệu khách hàng cần có phê duyệt trước khi dùng.

Dưới đây là ma trận nghiệm thu giả định với các phép thử đề xuất. Kết quả thực tế chỉ có sau khi kiểm thử. Tài chính và CNTT cần thay hoặc bổ sung ca cho phù hợp với hệ thống kế toán đang dùng.

Đặc biệt lưu ý trường hợp mất phản hồi. Kết nối có thể lỗi sau khi hệ thống đích đã chấp nhận bản ghi. Gửi lại ngay có thể tạo bản ghi thứ hai. Yêu cầu nhóm triển khai chứng minh cách khôi phục chống trùng trên giao diện thực tế và trình bày các giới hạn.

Ghi lại hành vi mong đợi, hành vi thực tế, bằng chứng và người chấp nhận kết quả. Trạng thái màu xanh cần đi kèm bản ghi có thể kiểm tra. Quyết định lỗi nào chặn triển khai và ai có quyền duyệt ngoại lệ có ghi nhận đối với quyết định đó.

Triển khai với kế hoạch đối soát và phương án dự phòng

Trước khi vận hành chính thức, thống nhất cách đối soát chứng từ tiếp nhận, ngoại lệ, bản ghi đích và các lượt phê duyệt đã hoàn tất. Mọi chứng từ đã nhận cần có trạng thái giải thích được. Tổng số có thể che khuất sai sót, nên đối chiếu cả mã định danh và các trường quan trọng.

Bắt đầu với một nhóm hóa đơn có kiểm soát. Mỗi hóa đơn chỉ đi theo một luồng tạo bản ghi thực tế để tránh quy trình thủ công và tự động cùng ghi. Nếu chạy song song để kiểm thử ngầm, cấu hình đầu ra không hạch toán và đối chiếu với quy trình được phép sử dụng.

Xác định trước điều kiện dừng. Có thể gồm thiếu bản ghi, tạo trùng chưa rõ nguyên nhân, chuyển sai người xử lý hoặc hàng đợi không có người giải quyết. Người phụ trách nghiệp vụ quyết định ngưỡng cụ thể. Ghi rõ ai có quyền tạm dừng tiếp nhận, giữ công việc đang chờ và khởi động lại an toàn.

Đào tạo người xử lý ngoại lệ, người duy trì dữ liệu nhà cung cấp và người duyệt hóa đơn. Cung cấp cho từng vai trò quy trình ngắn gọn cho phần việc của họ. Đưa cả phương án dự phòng vào nội dung đào tạo bên cạnh quy trình thông thường.

Dịch vụ nâng cao hiệu quả vận hành của Qonnex bao gồm tự động hóa chứng từ và kết nối công cụ sẵn có. Khi bàn triển khai, nên bắt đầu từ quy trình, quyền truy cập cần thiết và bằng chứng nghiệm thu. Việc thay hệ thống kế toán là một quyết định riêng.

Rà soát thí điểm trước khi thêm loại hóa đơn

So sánh thí điểm với đường cơ sở đã thống nhất theo cùng định nghĩa. Tính công rà soát, xử lý ngoại lệ, chi phí phần mềm và tích hợp, bảo trì cùng phần đối soát phát sinh. Tính cả công việc đã chuyển sang nhóm khác.

Xem phân bố kết quả trên nhiều loại hóa đơn. Nếu hóa đơn thông thường xử lý nhanh hơn nhưng ngoại lệ tồn lâu hơn, đó là phát hiện về thiết kế và có thể cần chỉnh thêm trước khi mở rộng. Tách phép tính tiết kiệm khỏi biên bản nghiệm thu kỹ thuật và áp dụng các nguyên tắc trong bài đo hiệu quả đầu tư tự động hóa.

Khi mở rộng, cần quyết định lại phạm vi. Thêm pháp nhân, tiền tệ, nhóm nhà cung cấp hoặc loại hóa đơn có thể kéo theo quy tắc khác. Dùng lại phần đã chứng minh được và kiểm thử lại phần thay đổi.

Tài liệu tiếp theo nên là bản đề cương thí điểm dài một trang gồm nhóm hóa đơn, người phụ trách, hệ thống đích, trường hợp loại trừ, chỉ số, phép thử nghiệm thu và điều kiện dừng. Để đánh giá quy trình với Qonnex, hãy dùng Bản phân tích doanh nghiệp để mô tả cách quy trình đang vận hành. Điểm xuất phát càng cụ thể, cuộc trao đổi về triển khai càng sát thực tế.