Case study được trình bày ở mức độ ẩn danh, không nêu tên thương vụ, khách hàng, ngành cụ thể hoặc cấu trúc dữ liệu nội bộ. Nội dung tập trung vào cách tiếp cận và giá trị đạt được, không công khai chi tiết kỹ thuật triển khai.

Trong một thương vụ thẩm định đầu tư, dữ liệu đầu vào không phải lúc nào cũng nằm sẵn trong file Excel sạch. Có những trường hợp toàn bộ báo cáo tài chính chỉ tồn tại ở dạng PDF scan, trải dài qua nhiều công ty và nhiều năm tài chính. Nếu nhập tay toàn bộ, công việc không chỉ tốn thời gian mà còn tạo ra rủi ro sai số liệu ngay từ lớp đầu vào của mô hình định giá.

Vấn đề thật sự không nằm ở việc "đọc được chữ từ PDF". Phần khó hơn là biến những con số đã bóc tách thành một bộ dữ liệu có thể tin được: cùng một logic kế toán, cùng một cấu trúc so sánh, và có đủ bước kiểm tra chéo trước khi được dùng cho quyết định đầu tư.

Trong thực tế, đây không phải là bài toán bóc tách một vài bảng số liệu từ PDF. Dữ liệu nằm rải rác ở nhiều lớp: báo cáo tài chính scan, sổ kế toán, sao kê, file dòng tiền và mô hình định giá. Nếu mỗi lớp được xử lý riêng lẻ, người phân tích rất dễ có nhiều bảng đẹp nhưng không trả lời được câu hỏi quan trọng nhất: số liệu nào đủ tin cậy để dùng cho quyết định đầu tư?

Tóm tắt nhanh

  • Đầu vào gồm nhiều lớp dữ liệu rời rạc: BCTC scan, sổ kế toán, sao kê, dòng tiền và mô hình định giá.
  • Rủi ro lớn nhất không phải là thiếu dữ liệu, mà là dữ liệu sau khi nhập/bóc tách nhìn có vẻ hợp lý nhưng lệch logic kế toán.
  • Cách tiếp cận là tách bài toán thành các lớp: bóc tách, chuẩn hóa, đối chiếu và kiểm tra ngoại lệ trước khi đưa vào mô hình định giá.
  • Kết quả là chuyển trọng tâm từ nhập liệu thủ công sang rà soát số liệu, giảm đáng kể thời gian xử lý và rủi ro sai ở lớp đầu vào.

1. Vấn đề

Khối lượng dữ liệu cần xử lý lớn: nhiều pháp nhân, nhiều năm tài chính, nhiều bộ báo cáo scan. Trong khi đó, báo cáo qua các năm không luôn cùng một mẫu biểu; một số chỉ tiêu thay tên, đổi vị trí hoặc được trình bày theo cấu trúc khác nhau. Nếu chỉ gõ lại từng dòng vào Excel, quy trình sẽ chậm, dễ sai và rất khó biết lỗi nằm ở đâu khi số liệu cuối cùng không khớp.

Bên cạnh BCTC, một case thẩm định còn cần nối với các lớp dữ liệu vận hành khác như sổ kế toán, sao kê ngân hàng, bảng dòng tiền và mô hình định giá. Mỗi nguồn dữ liệu có cấu trúc riêng, mức độ sạch khác nhau và mục đích sử dụng khác nhau. Nếu không thiết kế lớp dữ liệu chung, người phân tích sẽ mất rất nhiều thời gian để ghép số thủ công nhưng vẫn khó nhìn ra điểm bất thường.

Với dữ liệu phục vụ mô hình định giá, sai sót đầu vào có thể lan rất xa. Một số dư bị nhập lệch, một khoản mục bị ánh xạ sai, hoặc một kỳ báo cáo bị hiểu nhầm có thể làm thay đổi kết quả phân tích dòng tiền, tài sản, nợ phải trả hoặc các chỉ số so sánh. Vì vậy, mục tiêu không phải là làm nhanh bằng mọi giá, mà là tạo được một lớp dữ liệu đủ kiểm soát.

2. Ràng buộc

Dữ liệu gốc chỉ có ở dạng file quét, không có bảng số liệu sẵn để đối chiếu. Một số báo cáo cũ và mới không cùng khuôn mẫu, nên không thể áp dụng một template cứng cho toàn bộ. Ngoài ra, vì đây là dữ liệu phục vụ thẩm định đầu tư, quy trình phải giữ được tính bảo mật, không nêu thông tin nhận diện và không phụ thuộc mù quáng vào kết quả trích xuất tự động.

Ràng buộc quan trọng nhất là: sau khi dữ liệu được chuyển sang dạng bảng, nó vẫn chưa được xem là dùng được. Dữ liệu chỉ được dùng tiếp khi đã đi qua các điểm kiểm tra nghiệp vụ cơ bản, ví dụ tổng tài sản phải khớp tổng nguồn vốn, số dư đầu kỳ phải liên thông với số dư cuối kỳ trước, và các nhóm chỉ tiêu phải được đưa về cùng một logic so sánh.

3. Hướng tiếp cận

Tôi chia bài toán thành nhiều lớp. Lớp thứ nhất là chuyển dữ liệu từ PDF scan sang dạng có thể xử lý. Lớp thứ hai là chuẩn hóa các khoản mục về một cấu trúc thống nhất, để báo cáo của các công ty và các năm khác nhau có thể đặt cạnh nhau mà không bị lệch ngữ nghĩa. Lớp thứ ba là đối chiếu với sổ kế toán, sao kê và dòng tiền vận hành để phát hiện các điểm cần rà soát thêm. Lớp cuối cùng là kiểm tra chéo theo logic kế toán trước khi số liệu được đưa vào mô hình định giá.

Điểm chính không nằm ở công cụ bóc tách. Công cụ chỉ giúp rút ngắn phần nhập liệu. Phần quyết định chất lượng nằm ở thiết kế lớp kiểm soát: biết chỉ tiêu nào cần khớp, quan hệ nào phải kiểm tra, khoản mục nào dễ bị ánh xạ sai khi mẫu biểu thay đổi, và khi nào cần dừng lại để rà soát thủ công.

Vì sao kiểm tra chéo quan trọng hơn thao tác bóc tách: một con số đọc sai có thể phát hiện khi đối chiếu lại dòng gốc. Nhưng một khoản mục bị đưa nhầm nhóm, hoặc hai báo cáo theo hai mẫu biểu khác nhau được cộng gộp mà chưa chuẩn hóa, sẽ tạo ra lỗi âm thầm hơn nhiều: bảng tổng hợp nhìn vẫn gọn, nhưng kết luận phân tích phía sau đã bị lệch.

4. Kết quả

  • Giảm đáng kể thời gian xử lý so với việc nhập tay toàn bộ số liệu từ PDF scan, đặc biệt khi dữ liệu trải qua nhiều công ty và nhiều năm.
  • Chuyển phần lớn công sức từ nhập liệu lặp lại sang rà soát các điểm có rủi ro cao hơn: mẫu biểu thay đổi, khoản mục dễ nhầm, chỉ tiêu cần kiểm tra chéo.
  • Tạo được một lớp dữ liệu có cấu trúc hơn trước khi đưa vào mô hình định giá, thay vì đưa trực tiếp dữ liệu thô từ báo cáo scan vào file tính.
  • Tạo được cầu nối giữa dữ liệu kế toán lịch sử, dòng tiền vận hành và mô hình định giá, giúp quá trình thẩm định đi từ "nhập và ghép số" sang "kiểm tra ngoại lệ và đánh giá rủi ro".
  • Giảm rủi ro sai sót lan truyền từ dữ liệu đầu vào sang kết luận thẩm định, vì các quan hệ kế toán cơ bản đã được kiểm tra trước.

5. Điều rút ra

Với dữ liệu tài chính, tự động hóa chỉ có giá trị khi được đặt sau một lớp hiểu nghiệp vụ đủ sâu. Nếu chỉ biết công cụ, người làm có thể dừng ở việc "trích xuất được bảng". Nhưng để bảng đó dùng được cho thẩm định đầu tư, cần hiểu số liệu phải liên kết với nhau như thế nào, khoản mục nào có thể đổi tên qua các năm, và điểm nào bắt buộc phải kiểm tra trước khi ra quyết định.

Đây là ranh giới giữa một thao tác số hóa dữ liệu và một hệ thống phân tích đáng tin: không phải làm cho dữ liệu trông sạch hơn, mà làm cho dữ liệu đủ kiểm soát để người ra quyết định có thể dựa vào.