Xác định hoạt động sản xuất sản phẩm phần mềm là vấn đề quan trọng đối với doanh nghiệp công nghệ, đặc biệt trong bối cảnh ngành phần mềm ngày càng phát triển và có sự giao thoa với nhiều hoạt động dịch vụ công nghệ thông tin khác.
Doanh nghiệp công nghệ tại Bắc Ninh đang “làm phần mềm” hay thực sự “sản xuất sản phẩm phần mềm”?
Trong thực tế, cụm từ “công ty phần mềm” được sử dụng rất rộng. Một doanh nghiệp có đội ngũ developer, nhận dự án viết code, sửa lỗi hệ thống hoặc vận hành ứng dụng cho khách hàng đều có thể tự giới thiệu mình là doanh nghiệp phần mềm. Tuy nhiên, dưới góc độ pháp lý và thuế, câu hỏi cần đặt ra sâu hơn: doanh nghiệp đang cung cấp dịch vụ liên quan đến phần mềm hay đang thực hiện hoạt động sản xuất sản phẩm phần mềm đáp ứng quy trình?
Sự khác biệt này đặc biệt đáng lưu ý tại Bắc Ninh, nơi tập trung nhiều doanh nghiệp điện tử, doanh nghiệp FDI, nhà máy và chuỗi cung ứng công nghiệp. Một công ty công nghệ có thể vừa viết phần mềm quản lý kho, vừa triển khai MES cho nhà máy, vừa bảo trì hệ thống và bán thiết bị. Nếu toàn bộ doanh thu đều được gom chung dưới tên “doanh thu phần mềm”, doanh nghiệp rất dễ xác định sai bản chất hoạt động khi áp dụng chính sách thuế.
Thông tư 13/2020/TT-BTTTT là văn bản quy định trực tiếp việc xác định hoạt động sản xuất sản phẩm phần mềm đáp ứng quy trình và có hiệu lực từ ngày 19/8/2020.
Vì sao doanh nghiệp viết code chưa chắc đã được xác định là sản xuất sản phẩm phần mềm?
Viết mã lệnh chỉ là một công đoạn trong quá trình hình thành phần mềm. Một lập trình viên có thể nhận specification, tài liệu thiết kế và kiến trúc hệ thống hoàn chỉnh từ khách hàng rồi chỉ chuyển các yêu cầu đó thành code. Trong trường hợp này, doanh nghiệp có tham gia vào quá trình tạo phần mềm nhưng chưa thể chỉ dựa vào việc “có viết code” để kết luận hoạt động đáp ứng quy trình sản xuất sản phẩm phần mềm theo Thông tư 13/2020/TT-BTTTT.
Điểm quan trọng của quy định hiện hành là doanh nghiệp phải thực hiện ít nhất một trong hai công đoạn: xác định yêu cầu hoặc phân tích và thiết kế đối với sản phẩm phần mềm đó. Vì vậy, doanh nghiệp chỉ thực hiện lập trình, viết mã lệnh hoặc chỉ kiểm tra, thử nghiệm đơn thuần sẽ không đáp ứng điều kiện này theo cách xác định của Thông tư 13.
Ví dụ, Công ty A tại Bắc Ninh nhận toàn bộ tài liệu thiết kế từ khách hàng Nhật Bản. Khách hàng quyết định chức năng, giao diện, kiến trúc và tiêu chuẩn kỹ thuật; Công ty A chỉ lập trình theo ticket rồi gửi code để khách hàng nghiệm thu. Trường hợp này phải được đánh giá khác với Công ty B tự khảo sát nhu cầu quản lý kho của nhà máy, xác định yêu cầu, thiết kế giải pháp WMS, lập trình, kiểm thử và triển khai hệ thống.
Do đó, khi rà soát doanh nghiệp, đừng bắt đầu bằng câu hỏi “Có bao nhiêu lập trình viên?” mà nên bắt đầu bằng câu hỏi “Doanh nghiệp thực sự làm những công đoạn nào để tạo ra sản phẩm?”
Gia công phần mềm, phát triển phần mềm và sản xuất sản phẩm phần mềm khác nhau ở đâu?
“Gia công phần mềm”, “phát triển phần mềm” và “sản xuất sản phẩm phần mềm” có thể giao nhau trong thực tế nhưng không nên mặc nhiên xem là đồng nghĩa.
Gia công phần mềm thường nhấn mạnh quan hệ đặt hàng: khách hàng giao một phần hoặc toàn bộ yêu cầu để doanh nghiệp thực hiện. Phạm vi có thể chỉ là coding, testing hoặc cũng có thể rộng đến phân tích, thiết kế và hoàn thiện sản phẩm. Vì vậy, không nên kết luận mọi hợp đồng outsourcing đều không đáp ứng quy trình; phải xem doanh nghiệp thực tế đảm nhận công đoạn nào.
Phát triển phần mềm là khái niệm rộng hơn, có thể bao gồm việc xây dựng mới, cải tiến, bổ sung module, nâng cấp phiên bản hoặc hoàn thiện hệ thống.
Trong khi đó, khi xem xét hoạt động sản xuất sản phẩm phần mềm đáp ứng quy trình, doanh nghiệp cần đối chiếu đồng thời sản phẩm tạo ra và các công đoạn thực tế theo Thông tư 13/2020/TT-BTTTT.
Có thể hình dung:
Hợp đồng → Công việc thực tế → Sản phẩm tạo ra → Công đoạn thực hiện → Hồ sơ chứng minh → Xác định chính sách thuế.
Tên hợp đồng chỉ là điểm xuất phát. Một hợp đồng mang tên “Hợp đồng gia công phần mềm” chưa tự động quyết định kết quả pháp lý.
Doanh nghiệp trong KCN Bắc Ninh có phần mềm phục vụ nhà máy thì xác định thế nào?
Đây là tình huống cần tách riêng.
Một doanh nghiệp sản xuất linh kiện điện tử trong KCN có thể có 20 kỹ sư IT xây dựng hệ thống theo dõi sản lượng, quản lý lỗi, điều phối nguyên liệu hoặc kết nối máy móc. Việc doanh nghiệp có một đội lập trình nội bộ chưa đồng nghĩa toàn bộ doanh nghiệp trở thành doanh nghiệp sản xuất phần mềm.
Cần xác định:
Phần mềm nào đang được tạo ra?
Phần mềm có thể nhận diện thành một sản phẩm cụ thể hay chỉ là cấu phần phục vụ hoạt động nội bộ?
Doanh nghiệp thực hiện những công đoạn nào?
Chi phí nhân sự và chi phí phát triển phần mềm được hạch toán ra sao?
Phần mềm được sử dụng nội bộ, chuyển giao cho công ty trong tập đoàn hay thương mại hóa cho khách hàng?
Có tài liệu thể hiện yêu cầu, thiết kế, code, kiểm thử và phiên bản sản phẩm hay không?
Đặc biệt, nếu doanh nghiệp vừa sản xuất phần cứng vừa phát triển firmware hoặc phần mềm nhúng, việc tách hoạt động, chi phí và doanh thu càng quan trọng.
Vì sao xác định đúng bản chất hoạt động quan trọng với thuế và ưu đãi doanh nghiệp?
Thông tư 13/2020/TT-BTTTT được ban hành làm căn cứ xác định hoạt động sản xuất sản phẩm phần mềm đáp ứng quy trình, có liên hệ trực tiếp đến việc xem xét chính sách ưu đãi thuế đối với hoạt động sản xuất phần mềm.
Doanh nghiệp cũng cần lưu ý rằng cơ chế hiện hành không phải là cứ xin một “giấy chứng nhận doanh nghiệp sản xuất phần mềm” rồi mặc nhiên được hưởng ưu đãi. Cơ quan quản lý đã hướng dẫn rằng doanh nghiệp tự xác định hoạt động sản xuất phần mềm đáp ứng quy trình và tự chịu trách nhiệm về tính xác thực của thông tin trong hồ sơ đề xuất ưu đãi thuế.
Vì vậy, hồ sơ chứng minh cần được xây từ hoạt động thật, không nên làm ngược theo hướng “đến khi kiểm tra thuế mới dựng lại quy trình”.
Bài test 3 lớp – xác định một hoạt động có phải sản xuất sản phẩm phần mềm hay không
Một cách thực tế để doanh nghiệp Bắc Ninh tự rà soát là sử dụng bài test 3 lớp. Mỗi dự án, sản phẩm hoặc dòng doanh thu nên được đưa qua cả ba lớp thay vì chỉ nhìn vào ngành nghề đăng ký kinh doanh.
Lớp 1 – doanh nghiệp có tạo mới, nâng cấp, sửa đổi hoặc hoàn thiện phần mềm không?
Trước tiên phải xác định đối tượng doanh nghiệp đang tạo ra.
Nếu doanh nghiệp chỉ bán lại license của một hãng khác, cung cấp server, cho thuê nhân sự IT hoặc hỗ trợ người dùng thì bản chất rất khác với việc trực tiếp tạo ra hoặc phát triển một sản phẩm phần mềm.
Ngược lại, nếu doanh nghiệp tiếp nhận nhu cầu, thiết kế giải pháp, xây dựng module mới, phát triển tính năng, sửa đổi kiến trúc hoặc tạo phiên bản phần mềm mới thì đã có cơ sở để tiếp tục sang lớp kiểm tra tiếp theo.
Tại bước này nên lập một “hồ sơ nhận diện sản phẩm” gồm:
Tên sản phẩm → mục đích → chức năng chính → phiên bản → khách hàng/người sử dụng → thời gian phát triển → đội dự án → quyền sở hữu → hình thức thương mại hóa.
Lớp 2 – sản phẩm tạo ra có thuộc Danh mục sản phẩm phần mềm không?
Không phải cứ tạo ra thứ gì có code cũng tự động kết luận đó là sản phẩm phần mềm thuộc danh mục pháp lý.
Doanh nghiệp cần đối chiếu Danh mục sản phẩm phần mềm được ban hành tại Thông tư 09/2013/TT-BTTTT và các nội dung sửa đổi, bổ sung tại Thông tư 20/2021/TT-BTTTT.
Đây là bước đặc biệt quan trọng đối với những sản phẩm “lai”, chẳng hạn:
thiết bị IoT đi kèm phần mềm;
máy móc có firmware;
dây chuyền có chương trình điều khiển;
nền tảng SaaS;
hệ thống quản lý nhà máy;
website có chức năng nghiệp vụ phức tạp;
thiết bị điện tử đi kèm ứng dụng mobile.
Doanh nghiệp nên mô tả chức năng thực tế của sản phẩm rồi mới tìm nhóm tương ứng trong danh mục, thay vì chọn tên gần giống nhất chỉ để hoàn thiện hồ sơ.
Lớp 3 – doanh nghiệp thực hiện công đoạn nào trong quy trình sản xuất?
Đây là lớp quyết định.
Thông tư 13/2020/TT-BTTTT quy định quy trình sản xuất sản phẩm phần mềm theo các công đoạn và đặt điều kiện để hoạt động được xác định là đáp ứng quy trình. Điểm đáng chú ý là doanh nghiệp phải thực hiện ít nhất một trong hai công đoạn xác định yêu cầu hoặc phân tích và thiết kế đối với sản phẩm đang xét.
Do đó, cần lập ma trận cho từng sản phẩm:
Công đoạn → doanh nghiệp có thực hiện không → bộ phận thực hiện → tài liệu đầu vào → kết quả đầu ra → bằng chứng lưu trữ.
Ví dụ:
“Xác định yêu cầu” không nên chỉ được chứng minh bằng một dòng trong hợp đồng. Có thể cần user requirement, biên bản khảo sát, backlog, user story, tài liệu đặc tả hoặc lịch sử trao đổi với khách hàng.
“Phân tích và thiết kế” có thể được thể hiện qua tài liệu kiến trúc, database design, API specification, wireframe, prototype, sơ đồ luồng dữ liệu hoặc tài liệu thiết kế kỹ thuật.
Khi nào kết quả của cả 3 lớp đủ cơ sở để xây hồ sơ chứng minh?
Khi doanh nghiệp trả lời rõ được cả ba vấn đề:
Một – đang tạo ra sản phẩm gì?
Hai – sản phẩm được phân loại ở đâu trong Danh mục sản phẩm phần mềm?
Ba – doanh nghiệp thực hiện những công đoạn nào và có tài liệu chứng minh hay không?
Lúc đó mới nên chuyển sang bước xây dựng hồ sơ phục vụ kế toán, thuế và quản trị ưu đãi.
Điểm cần nhấn mạnh là doanh nghiệp không cần một văn bản xác nhận của cơ quan chuyên ngành mới được xem xét vấn đề ưu đãi; hướng dẫn của cơ quan quản lý xác định trách nhiệm tự xác định và chứng minh thuộc về doanh nghiệp.
Bản đồ 7 công đoạn sản xuất phần mềm – doanh nghiệp Bắc Ninh đang đứng ở đâu?
Thông tư 13/2020/TT-BTTTT quy định quy trình sản xuất sản phẩm phần mềm gồm 7 công đoạn. Việc nhận diện đúng từng công đoạn giúp doanh nghiệp biến hoạt động kỹ thuật hằng ngày thành một hệ thống chứng cứ có thể kiểm tra được.
Xác định yêu cầu – dấu vết đầu tiên của quá trình tạo sản phẩm
Đây là giai đoạn trả lời câu hỏi: Phần mềm phải giải quyết vấn đề gì?
Đối với phần mềm quản lý nhà máy tại Bắc Ninh, yêu cầu có thể xuất phát từ việc cần theo dõi sản lượng từng line, kiểm soát lỗi, truy xuất linh kiện, quản lý tồn kho hoặc kết nối dữ liệu máy móc.
Hồ sơ nên giữ lại có thể gồm:
Requirement document, biên bản khảo sát, email yêu cầu, user story, product backlog, ticket, biên bản họp với khách hàng, tài liệu mô tả nghiệp vụ và phiên bản yêu cầu.
Một lỗi thường gặp là developer thực tế đã trao đổi hàng trăm yêu cầu với khách hàng qua Jira, Teams hoặc email nhưng doanh nghiệp không có quy trình lưu trữ tập trung. Khi cần chứng minh, dữ liệu nằm rải rác trong tài khoản của nhân sự đã nghỉ việc.
Phân tích và thiết kế – công đoạn quyết định kiến trúc sản phẩm
Sau khi biết khách hàng cần gì, đội dự án phải xác định phần mềm sẽ được xây dựng như thế nào.
Đây có thể là quá trình:
Yêu cầu → phân tích nghiệp vụ → thiết kế kiến trúc → thiết kế cơ sở dữ liệu → thiết kế API → thiết kế giao diện → thiết kế bảo mật → xác định công nghệ.
Các tài liệu như system architecture, ERD, UML, wireframe, prototype, database schema, API specification và technical design document có giá trị rất lớn.
Đối với doanh nghiệp muốn chứng minh hoạt động sản xuất phần mềm, đây không chỉ là tài liệu của developer mà còn là một phần của hồ sơ pháp lý – thuế của dự án.
Lập trình, viết mã lệnh có tự mình đủ để chứng minh sản xuất không?
Không.
Đây chính là điểm doanh nghiệp outsourcing cần đặc biệt chú ý. Theo hướng dẫn công bố khi Thông tư 13/2020/TT-BTTTT được ban hành, doanh nghiệp chỉ thực hiện lập trình, viết mã lệnh hoặc kiểm tra, thử nghiệm sẽ không đáp ứng điều kiện về quy trình nếu không thực hiện ít nhất một trong hai công đoạn xác định yêu cầu hoặc phân tích và thiết kế.
Ví dụ:
Khách hàng gửi design hoàn chỉnh → doanh nghiệp nhận ticket → developer code → QA test → giao source code.
Không nên nhìn chuỗi công việc này rồi mặc nhiên kết luận rằng cứ có developer và source code là đủ.
Ngược lại:
Khách hàng đưa bài toán → doanh nghiệp khảo sát → xác định yêu cầu → thiết kế hệ thống → lập trình → kiểm thử → bàn giao.
Chuỗi thứ hai có nền tảng chứng minh mạnh hơn đáng kể.
Kiểm tra, thử nghiệm và hoàn thiện phần mềm cần lưu hồ sơ gì?
Testing thường để lại rất nhiều dấu vết kỹ thuật nhưng lại ít được doanh nghiệp đưa vào bộ hồ sơ chứng minh.
Nên lưu:
test plan;
test case;
test report;
bug report;
lịch sử ticket;
kết quả UAT;
biên bản nghiệm thu;
lịch sử sửa lỗi;
phiên bản build;
release note.
Ví dụ, một hệ thống MES được chạy thử tại nhà máy trong ba tuần và phát hiện 48 lỗi. Nếu toàn bộ lỗi, người xử lý, phiên bản sửa và kết quả kiểm tra lại đều được lưu trên hệ thống quản lý dự án thì đây là chuỗi chứng cứ tốt hơn nhiều so với một biên bản cuối cùng chỉ ghi “phần mềm hoạt động ổn định”.
Cài đặt, chuyển giao, phát hành và bảo trì nằm ở đâu trong vòng đời sản phẩm?
Sau khi hoàn thành sản phẩm, doanh nghiệp còn có thể thực hiện đóng gói, cài đặt, tích hợp, hướng dẫn sử dụng, chuyển giao, phát hành, phân phối và các hoạt động liên quan trong vòng đời phần mềm theo phạm vi quy trình được quy định.
Đặc biệt, Thông tư 13 đã bổ sung hình thức cho thuê sản phẩm phần mềm như một dịch vụ trong nội dung phát hành, phân phối. Điều này phù hợp với mô hình SaaS thay vì chỉ coi bán license là phương thức đưa sản phẩm ra thị trường.
Tuy nhiên, doanh nghiệp phải phân biệt hoạt động tạo sản phẩm với doanh thu phát sinh sau đó từ hỗ trợ, vận hành, đào tạo, bảo trì hoặc các dịch vụ khác. Không nên mặc nhiên gom mọi khoản thu sau khi phần mềm được bàn giao thành một loại doanh thu.
“Có code nhưng chưa chắc đủ” – những mô hình dễ xác định sai nhất
Các doanh nghiệp phần mềm tại Bắc Ninh thường không vận hành theo một mô hình duy nhất. Một công ty có thể cùng lúc làm outsourcing cho Nhật Bản, phát triển ERP cho nhà máy trong tỉnh và bán SaaS cho doanh nghiệp nhỏ. Vì vậy, nên đánh giá theo từng sản phẩm, dự án và dòng doanh thu.
Công ty chỉ nhận coding từ bản thiết kế của khách hàng
Đây là trường hợp điển hình cần cảnh giác.
Nếu khách hàng đã thực hiện toàn bộ requirement và system design, doanh nghiệp chỉ nhận specification rồi lập trình theo yêu cầu thì công đoạn thực tế của doanh nghiệp chủ yếu nằm ở coding.
Theo cách xác định hiện hành, chỉ coding đơn thuần không phải căn cứ đủ để đáp ứng điều kiện tối thiểu của quy trình.
Doanh nghiệp outsourcing vì vậy nên rà từng loại hợp đồng thay vì áp dụng chung một kết luận cho toàn bộ doanh thu.
Công ty chỉ thực hiện testing và sửa lỗi
Testing là một phần quan trọng của quá trình tạo phần mềm nhưng nếu doanh nghiệp chỉ nhận bản build từ khách hàng, chạy test case, báo lỗi và kiểm tra lại thì cũng không nên mặc nhiên xác định đây là hoạt động đáp ứng quy trình.
Đặc biệt cần phân biệt:
Testing trong dự án mà doanh nghiệp đồng thời tham gia requirement/design với dịch vụ kiểm thử độc lập.
Hai mô hình có thể sử dụng cùng một đội QA nhưng bản chất chuỗi hoạt động hoàn toàn khác.
Công ty nhận cả yêu cầu, thiết kế kiến trúc và lập trình
Đây là mô hình có cơ sở chứng minh rõ hơn.
Ví dụ, một nhà máy tại Yên Phong cần hệ thống quản lý bảo trì thiết bị. Công ty phần mềm khảo sát quy trình nhà máy, xác định yêu cầu, thiết kế kiến trúc, xây database, lập trình web/mobile, kiểm thử rồi triển khai.
Trong trường hợp này, hồ sơ có thể hình thành thành một chuỗi:
Biên bản khảo sát → Requirement → System Design → Source Code → Test → UAT → Release → Nghiệm thu.
Chuỗi chứng cứ càng liền mạch thì việc giải trình bản chất hoạt động càng thuận lợi.
Đội IT nội bộ phát triển phần mềm phục vụ chính doanh nghiệp
Trường hợp này phải phân tích thận trọng hơn.
Ví dụ, một công ty điện tử có đội IT viết chương trình kiểm soát sản xuất chỉ sử dụng trong nhà máy. Về kỹ thuật, đội IT có thể thực hiện đầy đủ requirement, design, coding và testing. Tuy nhiên, khi xem xét chính sách thuế, không thể chỉ lấy việc “có quy trình phát triển phần mềm” làm kết luận cuối cùng.
Cần tiếp tục xem xét hoạt động đầu tư, sản phẩm, chủ thể tạo sản phẩm, mục đích sử dụng, cách ghi nhận chi phí – tài sản và dòng doanh thu liên quan.
Nói cách khác:
Có sản phẩm phần mềm + có quy trình là điều kiện cần phân tích, nhưng chưa nên đồng nhất ngay với mọi điều kiện để hưởng một ưu đãi thuế cụ thể.
Công ty bảo trì, nâng cấp sản phẩm đã có của khách hàng
“Bảo trì” và “nâng cấp” cần được bóc tách.
Nếu công việc chỉ là giám sát server, hỗ trợ người dùng, xử lý sự cố và sửa lỗi nhỏ thì bản chất khác với một dự án phát triển phiên bản mới có yêu cầu mới, thiết kế mới, module mới và quá trình kiểm thử – phát hành mới.
Doanh nghiệp nên tránh dùng một hợp đồng chung mang tên “bảo trì và phát triển phần mềm” cho tất cả công việc rồi hạch toán toàn bộ doanh thu theo cùng một cách.
Tốt hơn là tách:
Phí bảo trì định kỳ – phí vận hành – phí support – phí phát triển tính năng – phí nâng cấp phiên bản – phí license/SaaS.
Sản phẩm của doanh nghiệp có thực sự nằm trong “Danh mục sản phẩm phần mềm”?
Sau khi xác định doanh nghiệp thực sự tham gia quá trình tạo sản phẩm, câu hỏi tiếp theo là sản phẩm đó được phân loại thế nào?
Thông tư 09/2013/TT-BTTTT ban hành Danh mục sản phẩm phần mềm và phần cứng, điện tử; danh mục này đã được sửa đổi, bổ sung bởi Thông tư 20/2021/TT-BTTTT.
Phần mềm hệ thống được nhận diện như thế nào?
Nhóm phần mềm hệ thống thường liên quan đến việc tạo môi trường hoặc nền tảng phục vụ vận hành thiết bị, máy tính hoặc các hệ thống công nghệ.
Khi phân loại, doanh nghiệp không nên chỉ dựa vào tên thương mại. Một sản phẩm mang tên “Smart Factory Core” chưa nói lên nó thuộc nhóm nào.
Cần mô tả:
Sản phẩm chạy ở đâu → điều khiển cái gì → tương tác với phần cứng nào → chức năng chính → người sử dụng → dữ liệu đầu vào/đầu ra.
Từ mô tả kỹ thuật đó mới đối chiếu danh mục pháp lý.
Phần mềm ứng dụng cho doanh nghiệp có thuộc danh mục không?
Nhiều phần mềm phục vụ quản trị doanh nghiệp có thể được xem xét trong các nhóm sản phẩm phần mềm ứng dụng tương ứng theo danh mục.
Đây là nhóm rất đáng quan tâm tại Bắc Ninh bởi các nhà máy có nhu cầu lớn về:
ERP, MES, WMS, CRM, HRM, quản lý chất lượng, quản lý bảo trì, truy xuất nguồn gốc, quản lý sản xuất và dashboard điều hành.
Tuy nhiên, tên gọi “ERP” hay “MES” không phải chiếc tem pháp lý tự động. Doanh nghiệp vẫn phải xác định đúng sản phẩm cụ thể và chứng minh quy trình tạo sản phẩm.
App, nền tảng SaaS, website có chức năng phần mềm xác định ra sao?
Không nên dùng hình thức truy cập để quyết định bản chất sản phẩm.
Một phần mềm chạy trên trình duyệt vẫn có thể là một ứng dụng phần mềm. Một nền tảng SaaS cũng không mất bản chất phần mềm chỉ vì khách hàng trả phí thuê bao hàng tháng thay vì mua license vĩnh viễn.
Ngược lại, một website giới thiệu doanh nghiệp gồm vài trang thông tin không nên được gọi thành “sản phẩm phần mềm” chỉ vì website có source code.
Cần nhìn vào chức năng thực tế:
Website giới thiệu ≠ hệ thống quản trị nghiệp vụ chạy trên web.
Landing page ≠ nền tảng SaaS.
Trang đặt hàng đơn giản ≠ mặc nhiên là một hệ thống phần mềm độc lập.
Phần mềm nhúng trong máy móc, dây chuyền sản xuất tại Bắc Ninh xử lý thế nào?
Đây là vấn đề thường gặp trong ngành điện tử.
Firmware hoặc embedded software có thể nằm trong bo mạch, thiết bị IoT, máy đo, robot, bộ điều khiển hoặc sản phẩm điện tử khác. Khi đó, doanh nghiệp cần xác định phần nào là sản phẩm phần cứng và phần nào là phần mềm.
Hồ sơ nên thể hiện được:
Firmware làm gì → chạy trên thiết bị nào → ai phát triển → có version riêng không → source code nằm ở đâu → có quy trình requirement/design/test không → quyền sở hữu thuộc về ai.
Không nên vì phần mềm được “nhúng” vào thiết bị mà bỏ toàn bộ hồ sơ phát triển phần mềm.
Một dự án có cả phần cứng và phần mềm cần tách sản phẩm ra sao?
Ví dụ một hợp đồng Smart Factory trị giá 5 tỷ đồng gồm:
máy quét mã vạch + cảm biến + gateway + server + phần mềm quản lý + triển khai + đào tạo + bảo trì.
Nếu hợp đồng chỉ ghi một dòng “Hệ thống quản lý nhà máy: 5 tỷ đồng”, việc xác định doanh thu và giải trình thuế về sau có thể rất khó.
Ngay từ báo giá và hợp đồng nên cân nhắc tách hợp lý:
Phần cứng | Phần mềm | License/SaaS | Triển khai | Tích hợp | Đào tạo | Bảo trì | Dịch vụ khác.
Việc bóc tách phải phản ánh giao dịch thực tế và phương pháp kế toán phù hợp, không phải chia giá trị hình thức chỉ nhằm tạo cơ sở ưu đãi.
Bắc Ninh và bài toán phần mềm cho nhà máy – đây là “ngách” cần phân tích riêng
Với đặc điểm tập trung nhiều nhà máy điện tử và doanh nghiệp FDI, Bắc Ninh tạo ra một nhóm dự án phần mềm có tính chất rất khác phần mềm văn phòng thông thường: phần mềm thường gắn trực tiếp với máy móc, dây chuyền, dữ liệu sản xuất và hệ thống quản trị của tập đoàn.
Do đó, một dự án có thể đồng thời chứa phần mềm, thiết bị, tích hợp hệ thống, dịch vụ kỹ thuật và bảo trì.
Phần mềm MES, ERP, quản lý kho và sản xuất có thể được nhìn nhận thế nào?
Không nên đánh giá chỉ dựa vào tên viết tắt.
Ví dụ, cùng được gọi là “MES” nhưng có ba tình huống:
Tình huống 1: Doanh nghiệp mua MES của hãng nước ngoài rồi bán lại license cho nhà máy.
Tình huống 2: Doanh nghiệp lấy một MES có sẵn rồi thực hiện cài đặt, cấu hình và hỗ trợ.
Tình huống 3: Doanh nghiệp khảo sát quy trình sản xuất, xác định yêu cầu, thiết kế kiến trúc và tự phát triển hệ thống MES.
Ba trường hợp có thể tạo ra trải nghiệm gần giống nhau cho khách hàng nhưng hoạt động của nhà cung cấp hoàn toàn khác.
Vì vậy, phải nhìn vào ai tạo sản phẩm và ai thực hiện các công đoạn của quy trình.
Phần mềm điều khiển thiết bị và dây chuyền có phải sản phẩm phần mềm độc lập?
Có thể có trường hợp phần mềm được nhận diện và quản lý tương đối độc lập, nhưng cũng có trường hợp nó gắn chặt với thiết bị.
Doanh nghiệp nên thử “bài test độc lập”:
Phần mềm có tên riêng không?
Có version không?
Có source code/repository riêng không?
Có tài liệu yêu cầu và thiết kế không?
Có thể cập nhật phần mềm mà không thay toàn bộ máy không?
Có được bàn giao, cấp quyền sử dụng hoặc phân phối riêng không?
Nếu càng nhiều câu trả lời là “có”, việc nhận diện cấu phần phần mềm càng rõ. Tuy nhiên, kết luận cuối cùng vẫn phải đối chiếu danh mục sản phẩm và quy trình pháp lý tương ứng.
Công ty điện tử viết firmware cho sản phẩm của mình cần tách hoạt động ra sao?
Ví dụ một doanh nghiệp tại Bắc Ninh sản xuất thiết bị IoT và có ba nhóm nhân sự:
Hardware team thiết kế bo mạch.
Firmware team phát triển chương trình nhúng.
Cloud team xây nền tảng quản lý thiết bị.
Nếu tất cả chi phí được gom vào một mã “R&D sản phẩm IoT”, về sau rất khó chứng minh hoạt động nào thuộc phần cứng và hoạt động nào thuộc phần mềm.
Doanh nghiệp nên quản trị theo:
Project → Product → Module → Team → Chi phí → Version → Hồ sơ kỹ thuật.
Repository firmware và cloud software nên được quản lý rõ; tài liệu requirement, architecture, testing và release cũng nên gắn với từng phiên bản.
Doanh nghiệp FDI thuê đội kỹ thuật tại Bắc Ninh phát triển phần mềm nội bộ có gì khác?
Điểm cần kiểm tra đầu tiên là đội kỹ thuật tại Việt Nam đang làm gì trong chuỗi phát triển toàn cầu.
Nếu công ty mẹ tại Hàn Quốc hoặc Nhật Bản quyết định toàn bộ requirement và architecture, còn đội Bắc Ninh chỉ nhận ticket để coding thì cần đánh giá theo đúng phạm vi công đoạn thực hiện tại Việt Nam.
Nếu đội tại Bắc Ninh trực tiếp làm việc với nhà máy, thu thập yêu cầu, phân tích nghiệp vụ, thiết kế giải pháp rồi lập trình thì bức tranh lại khác.
Đối với tập đoàn FDI, cần lưu thêm một lớp hồ sơ:
Ai giao việc → quyền sở hữu sản phẩm thuộc ai → chi phí được phân bổ thế nào → công ty Việt Nam được thanh toán theo cơ chế nào → sản phẩm được sử dụng ở đâu → giao dịch liên kết được thể hiện ra sao.
Không nên chỉ nhìn vào số lượng kỹ sư phần mềm đang làm việc tại Việt Nam.
Hợp đồng vừa có thiết bị vừa có phần mềm nên bóc tách doanh thu và hồ sơ thế nào?
Một hợp đồng Smart Factory tốt nên cho phép doanh nghiệp nhìn thấy từng lớp giá trị.
Ví dụ:
Lớp 1 – Thiết bị: server, gateway, sensor, scanner, PLC và thiết bị mạng.
Lớp 2 – Sản phẩm phần mềm: MES, WMS, dashboard, application hoặc module được phát triển.
Lớp 3 – Triển khai: cài đặt, cấu hình, migration và tích hợp.
Lớp 4 – Dịch vụ: đào tạo, hỗ trợ, vận hành và bảo trì.
Lớp 5 – Phát triển bổ sung: customization, module mới và phiên bản nâng cấp.
Tương ứng, hồ sơ kế toán và hồ sơ kỹ thuật cũng cần có khả năng nối với nhau:
Hợp đồng → phụ lục phạm vi → báo giá → project code → hồ sơ phát triển → nghiệm thu → hóa đơn → doanh thu → chi phí.
Đây chính là cách doanh nghiệp biến “chúng tôi có làm phần mềm” thành một chuỗi chứng cứ có thể kiểm tra.
Đối với doanh nghiệp công nghệ tại Bắc Ninh, mục tiêu không nên là cố đưa càng nhiều doanh thu càng tốt vào nhóm sản xuất phần mềm. Cách an toàn hơn là phân loại đúng ngay từ đầu: đâu là sản phẩm phần mềm, đâu là phần cứng, đâu là dịch vụ triển khai, đâu là bảo trì và đâu là hoạt động phát triển thực sự đáp ứng quy trình.
Thông tư 13/2020/TT-BTTTT đặt trọng tâm vào hoạt động thực tế và các công đoạn doanh nghiệp thực hiện; doanh nghiệp tự xác định và tự chịu trách nhiệm về hồ sơ của mình. Vì vậy, hồ sơ tốt nhất không phải bộ tài liệu được dựng khi cơ quan thuế yêu cầu giải trình, mà là bộ tài liệu được hình thành song song với từng sprint, từng version và từng lần nghiệm thu sản phẩm.
“Dấu vết sản xuất” – hồ sơ nào chứng minh doanh nghiệp thực sự làm ra phần mềm?
Một doanh nghiệp có thể sở hữu hàng trăm nghìn dòng source code nhưng khi cần giải trình vẫn gặp khó khăn nếu không chứng minh được source code đó hình thành từ sản phẩm nào, theo yêu cầu nào, ai thiết kế, ai phát triển và kết quả cuối cùng được nghiệm thu ra sao.
Đây là lý do hồ sơ chứng minh hoạt động phần mềm không nên được hiểu đơn giản là một folder gồm hợp đồng, hóa đơn và vài ảnh chụp màn hình sản phẩm. Hồ sơ mạnh phải tái hiện được toàn bộ “dấu vết sản xuất” từ lúc xuất hiện nhu cầu đến khi phần mềm được hoàn thiện và đưa vào sử dụng.
Với những giai đoạn áp dụng Thông tư 13/2020/TT-BTTTT, văn bản này từng yêu cầu hoạt động sản xuất một sản phẩm phần mềm phải thực hiện ít nhất một trong hai công đoạn xác định yêu cầu hoặc phân tích và thiết kế, đồng thời cho phép sử dụng nhiều loại tài liệu tương ứng với các tác nghiệp thực tế để chứng minh.
Đối với doanh nghiệp Bắc Ninh đang rà soát hồ sơ các năm trước hoặc xây dựng hệ thống quản trị kỹ thuật cho hiện tại, tư duy quan trọng nhất vẫn là:
Một sản phẩm → một chuỗi phát triển → một bộ chứng cứ có thể truy ngược.
Biên bản khảo sát và tài liệu xác định yêu cầu
Một dự án phần mềm thường bắt đầu trước khi developer viết dòng code đầu tiên.
Đối với doanh nghiệp cung cấp giải pháp cho nhà máy tại Bắc Ninh, giai đoạn đầu có thể là kỹ sư đến khảo sát dây chuyền, gặp bộ phận sản xuất, kiểm tra quy trình quản lý kho, ghi nhận dữ liệu từ máy móc hoặc phỏng vấn người sử dụng.
Ví dụ, khách hàng yêu cầu xây dựng hệ thống quản lý kho nguyên vật liệu. Hồ sơ ban đầu có thể gồm:
biên bản khảo sát hiện trạng;
biên bản họp với khách hàng;
bảng câu hỏi nghiệp vụ;
danh sách yêu cầu;
user story;
product backlog;
email xác nhận phạm vi;
tài liệu mô tả quy trình hiện tại;
tài liệu đề xuất quy trình mới;
biên bản thống nhất yêu cầu.
Giá trị của những tài liệu này nằm ở việc chúng cho thấy doanh nghiệp tham gia vào quá trình xác định bài toán của sản phẩm, chứ không đơn thuần nhận một bản specification hoàn chỉnh rồi viết code.
Ví dụ:
Nhà máy yêu cầu “giảm thời gian kiểm kho”.
Đội dự án khảo sát và xác định thành các yêu cầu cụ thể:
Quét QR nguyên vật liệu → xác định vị trí pallet → cảnh báo FIFO → đối chiếu tồn kho hệ thống → ghi nhận lịch sử nhập xuất.
Chuỗi chuyển đổi từ một nhu cầu kinh doanh thành yêu cầu chức năng chính là dấu vết rất đáng lưu giữ.
SRS, tài liệu phân tích nghiệp vụ và đặc tả chức năng
Sau khảo sát, yêu cầu cần được chuyển thành tài liệu mà đội kỹ thuật có thể sử dụng để phát triển sản phẩm.
SRS – Software Requirements Specification – thường là một trong những tài liệu có giá trị cao vì giúp trả lời:
Phần mềm phải làm gì?
Một bộ SRS tốt có thể thể hiện:
Đối tượng sử dụng → chức năng → dữ liệu đầu vào → dữ liệu đầu ra → quyền truy cập → yêu cầu hiệu năng → yêu cầu bảo mật → trường hợp ngoại lệ → điều kiện nghiệm thu.
Đối với dự án MES tại Bắc Ninh, chẳng hạn, tài liệu có thể mô tả:
Operator quét mã sản phẩm.
Hệ thống xác định production order.
Máy ghi nhận trạng thái công đoạn.
QC nhập kết quả kiểm tra.
Sản phẩm lỗi được chuyển sang khu vực xử lý.
Dashboard cập nhật sản lượng theo thời gian thực.
Điểm cần lưu ý là doanh nghiệp không nhất thiết phải gọi tài liệu này là “SRS”. Trong thực tế Agile, yêu cầu có thể nằm trong Jira, Azure DevOps, Notion, Confluence hoặc một hệ thống quản lý backlog.
Điều quan trọng không phải tên tài liệu mà là nội dung có đủ khả năng chứng minh quá trình phân tích và xác lập yêu cầu hay không.
Tài liệu thiết kế kiến trúc, database và giao diện
Nếu requirement trả lời câu hỏi “phần mềm cần làm gì”, tài liệu thiết kế trả lời câu hỏi:
“Doanh nghiệp quyết định xây phần mềm như thế nào?”
Đây là nhóm bằng chứng rất quan trọng đối với doanh nghiệp trực tiếp phát triển sản phẩm.
Tùy dự án, doanh nghiệp có thể lưu:
system architecture;
solution architecture;
database design;
ERD;
API specification;
UML;
sequence diagram;
flowchart;
wireframe;
UI/UX prototype;
security design;
integration architecture;
tài liệu lựa chọn công nghệ.
Ví dụ, một hệ thống quản lý sản xuất có thể được thiết kế:
PLC → Gateway → Message Queue → Backend → Database → Dashboard → ERP.
Sơ đồ kiến trúc như vậy giúp chứng minh doanh nghiệp không chỉ nhận nhiệm vụ “viết màn hình A” mà tham gia quyết định cấu trúc của sản phẩm.
Source code, version control và lịch sử phát triển
Source code là bằng chứng rất mạnh nhưng source code đứng một mình chưa kể được toàn bộ câu chuyện.
Một repository tốt có thể cung cấp:
ngày tạo project;
contributor;
commit;
branch;
pull request;
code review;
release tag;
lịch sử merge;
lịch sử thay đổi tính năng.
GitHub, GitLab, Bitbucket, Azure DevOps hoặc hệ thống Git nội bộ đều có thể giúp hình thành chuỗi chứng cứ kỹ thuật.
Ví dụ:
Requirement MES-102
→ Branch feature/MES-102
→ Commit
→ Pull Request
→ Code Review
→ Test
→ Merge
→ Release 2.1.0.
Đây là cách rất tốt để nối yêu cầu – người thực hiện – mã nguồn – phiên bản sản phẩm.
Doanh nghiệp Bắc Ninh có đội phát triển lớn đặc biệt nên xây quy trình này từ đầu, bởi nếu source code nằm trong máy cá nhân của developer hoặc repository không quản lý theo project thì vài năm sau gần như không thể dựng lại lịch sử chính xác.
Test case, biên bản nghiệm thu và tài liệu release
Một sản phẩm chưa hoàn chỉnh chỉ vì đã viết xong code.
Dấu vết tiếp theo cần thể hiện quá trình kiểm tra và hoàn thiện sản phẩm.
Doanh nghiệp nên lưu:
test plan;
test case;
test report;
bug report;
UAT;
biên bản chạy thử;
biên bản nghiệm thu;
release note;
deployment record;
tài liệu hướng dẫn sử dụng;
tài liệu bàn giao.
Ví dụ:
Version 1.0 → 126 test case → phát hiện 17 bug → sửa 17 bug → khách hàng UAT → phát hành Version 1.0.1 → nghiệm thu.
Chuỗi như vậy có sức thuyết phục cao hơn nhiều so với một biên bản duy nhất ghi “hai bên thống nhất phần mềm đã hoàn thành”.
Hồ sơ phải liên kết với từng sản phẩm thay vì lưu chung theo công ty
Một sai lầm phổ biến là doanh nghiệp có hàng chục sản phẩm nhưng chỉ có một folder chung:
“DOCUMENT SOFTWARE”.
Bên trong chứa lẫn:
Hợp đồng dự án A.
SRS dự án B.
Source code dự án C.
Biên bản nghiệm thu dự án D.
Khi cần chứng minh một dòng doanh thu cụ thể, doanh nghiệp không thể xác định tài liệu nào thuộc sản phẩm nào.
Nên tổ chức dữ liệu theo cấu trúc:
Product → Project → Version → Requirement → Design → Development → Test → Release → Acceptance → Revenue.
Ví dụ:
WMS-GM
Project: WMS-2026-01
Version: 2.0
Requirement: WMS-RQ
Design: WMS-DES
Repository: WMS-GIT
Testing: WMS-TEST
Release: WMS-R2.0
Contract: HD-WMS-01
Acceptance: NT-WMS-01
Invoice: INV-WMS-01.
Khi đó, chỉ cần chọn một sản phẩm là doanh nghiệp có thể truy lại toàn bộ vòng đời.
Một hợp đồng phần mềm tại Bắc Ninh nên đọc thế nào để xác định bản chất hoạt động?
Hợp đồng phần mềm không chỉ là chứng từ thương mại. Nó còn là một trong những tài liệu đầu tiên cho thấy doanh nghiệp được thuê để làm việc gì.
Tuy nhiên, hợp đồng không nên được đọc riêng lẻ. Cần đối chiếu nó với deliverables, hồ sơ kỹ thuật, nghiệm thu và hóa đơn để xác định hoạt động thực tế.
Hợp đồng ghi “dịch vụ lập trình” có bất lợi gì khi đối chiếu hoạt động thực tế?
Giả sử doanh nghiệp thực tế:
Khảo sát → xác định yêu cầu → thiết kế → lập trình → kiểm thử → bàn giao.
Nhưng hợp đồng chỉ ghi:
“Bên B cung cấp dịch vụ lập trình phần mềm”.
Cách mô tả này có thể khiến hồ sơ thương mại hẹp hơn hoạt động kỹ thuật thực tế.
Khi rà soát sau này, người đọc hợp đồng có thể hiểu rằng doanh nghiệp chỉ thực hiện coding.
Điều đó không có nghĩa chỉ vì một cụm từ trong hợp đồng mà toàn bộ bản chất dự án bị thay đổi. Tuy nhiên, doanh nghiệp sẽ phải dùng nhiều tài liệu khác để chứng minh phạm vi thực tế.
Vì vậy, hợp đồng nên mô tả đúng bản chất như:
khảo sát;
phân tích yêu cầu;
thiết kế giải pháp;
phát triển phần mềm;
kiểm thử;
triển khai;
bàn giao.
Không nên “nâng” nội dung hợp đồng vượt quá công việc thực tế chỉ để phục vụ hồ sơ thuế. Mục tiêu là đồng bộ tài liệu với hoạt động thật.
Deliverables cho thấy doanh nghiệp tham gia công đoạn nào?
Deliverables thường có giá trị hơn tên gọi của hợp đồng.
Nếu hợp đồng yêu cầu doanh nghiệp bàn giao:
SRS;
system architecture;
source code;
test report;
release package;
user manual;
thì có thể nhìn thấy tương đối rõ chuỗi công việc doanh nghiệp đã cam kết thực hiện.
Ngược lại, nếu deliverables chỉ gồm:
“developer 160 giờ/tháng” hoặc “source code theo specification do khách hàng cung cấp” thì bản chất lại khác.
Doanh nghiệp nên lập một bảng:
Deliverable | Công đoạn liên quan | Người tạo | Ngày hoàn thành | Tài liệu lưu trữ.
Đây là cầu nối rất hiệu quả giữa hợp đồng thương mại và hồ sơ kỹ thuật.
Quyền sở hữu source code và sản phẩm đầu ra nói lên điều gì?
Điều khoản sở hữu trí tuệ giúp hiểu mô hình kinh doanh nhưng không tự mình quyết định hoạt động có phải sản xuất sản phẩm phần mềm hay không.
Có dự án doanh nghiệp tự phát triển rồi sở hữu toàn bộ IP.
Có dự án doanh nghiệp phát triển theo yêu cầu và chuyển giao toàn bộ source code cho khách hàng.
Có dự án quyền sở hữu thuộc khách hàng ngay từ khi sản phẩm được tạo ra.
Có mô hình SaaS trong đó doanh nghiệp giữ IP và khách hàng chỉ có quyền sử dụng.
Do đó, cần đọc đồng thời:
Ai phát triển?
Ai quyết định requirement?
Ai thiết kế?
Ai sở hữu code?
Ai sở hữu sản phẩm đầu ra?
Khách hàng mua sản phẩm hay mua năng lực nhân sự?
Những thông tin này giúp nhận diện rõ hơn mô hình hoạt động.
Hợp đồng theo giờ nhân sự khác hợp đồng phát triển sản phẩm ra sao?
Hai hợp đồng có thể đều sử dụng developer nhưng logic thương mại khác nhau.
Time & Material / Staff Augmentation
Khách hàng mua:
Developer A – 160 giờ.
Tester B – 120 giờ.
Project Manager C – 40 giờ.
Khách hàng thường kiểm soát backlog và phân công công việc.
Trong trường hợp này, cần kiểm tra kỹ doanh nghiệp thực tế tham gia requirement/design đến đâu.
Product/Project Development
Khách hàng giao:
“Xây dựng hệ thống WMS đáp ứng Phụ lục 01.”
Doanh nghiệp chịu trách nhiệm:
khảo sát → thiết kế → phát triển → kiểm thử → bàn giao.
Kết quả thương mại là một sản phẩm hoặc module hoàn thành, không chỉ là số giờ kỹ sư.
Không phải mọi hợp đồng tính theo giờ đều đồng nghĩa chỉ cung cấp nhân lực. Nhưng đây là tín hiệu cần xem kỹ hoạt động thực tế.
Vì sao hợp đồng – hóa đơn – hồ sơ kỹ thuật phải kể cùng một câu chuyện?
Hãy giả định:
Hợp đồng: “dịch vụ tư vấn CNTT”.
Hóa đơn: “dịch vụ phần mềm”.
Biên bản nghiệm thu: “bàn giao thiết bị và phần mềm”.
Repository: “WMS Development”.
Báo cáo nội bộ: “outsourcing manpower”.
Năm tài liệu đang kể năm câu chuyện khác nhau.
Khi đó, vấn đề không nằm ở việc thiếu giấy tờ mà ở việc không thể xác định bản chất giao dịch.
Một bộ hồ sơ tốt nên có logic:
Hợp đồng: phát triển WMS.
Requirement: WMS-RQ-2026.
Design: WMS-ARCH-2026.
Repository: WMS.
Nghiệm thu: WMS Version 1.0.
Hóa đơn: phát triển phần mềm WMS theo hợp đồng X.
Mỗi tài liệu có chức năng khác nhau nhưng đều chỉ về cùng một sản phẩm.
Case Study – 5 tình huống doanh nghiệp Bắc Ninh thường gặp khi xác định hoạt động phần mềm
Không nên đánh giá hoạt động phần mềm chỉ bằng tên ngành nghề. Năm tình huống dưới đây cho thấy cùng có developer nhưng bản chất hoạt động có thể rất khác nhau.
Case 1 – công ty nhận yêu cầu, thiết kế và lập trình ứng dụng cho khách Nhật Bản
Công ty A tại Bắc Ninh ký hợp đồng xây dựng ứng dụng quản lý bảo trì.
Khách hàng cung cấp bài toán tổng thể.
Công ty A:
khảo sát nghiệp vụ;
phân tích yêu cầu;
lập SRS;
thiết kế database;
thiết kế kiến trúc;
lập trình;
test;
bàn giao source code.
Hồ sơ gồm:
Contract → Requirement → SRS → Architecture → Git → Test → UAT → Acceptance.
Đây là trường hợp có chuỗi tài liệu tương đối rõ để chứng minh doanh nghiệp trực tiếp tham gia vào quá trình hình thành sản phẩm.
Nếu rà soát các năm mà Thông tư 13/2020/TT-BTTTT còn được áp dụng, việc có tài liệu chứng minh công đoạn xác định yêu cầu hoặc phân tích và thiết kế đặc biệt quan trọng bởi đây từng là điều kiện tối thiểu mà Thông tư đặt ra.
Case 2 – doanh nghiệp chỉ cung cấp lập trình viên làm việc theo specification của khách
Công ty B ký hợp đồng:
“Cung cấp 10 Java Developer.”
Khách hàng:
xác định requirement;
thiết kế architecture;
viết specification;
quản lý backlog.
Developer tại Bắc Ninh chỉ:
nhận ticket;
code;
fix bug;
gửi pull request.
Trong trường hợp này, không nên chỉ lấy source code làm căn cứ kết luận doanh nghiệp đảm nhận cả quá trình phát triển sản phẩm.
Cần xác định chính xác:
Doanh nghiệp có tham gia requirement không?
Có tham gia design không?
Hay chỉ cung cấp nguồn lực thực hiện coding?
Đây chính là nhóm outsourcing dễ bị đánh đồng nhất với hoạt động sản xuất sản phẩm phần mềm.
Case 3 – nhà máy tại Bắc Ninh tự phát triển phần mềm quản lý sản xuất
Nhà máy C có bộ phận IT 25 người.
Bộ phận này tự xây dựng MES nội bộ.
Nhóm IT:
lấy yêu cầu từ phòng sản xuất;
thiết kế;
lập trình;
test;
deploy.
Về mặt kỹ thuật, quá trình phát triển phần mềm có thể rất rõ.
Nhưng khi xem xét ưu đãi thuế hoặc một chính sách cụ thể, doanh nghiệp không nên dừng tại kết luận:
“Có đủ quy trình nên chắc chắn được hưởng ưu đãi.”
Cần xem thêm:
chủ thể đang hưởng ưu đãi;
hoạt động đầu tư;
doanh thu;
cách ghi nhận sản phẩm;
mục đích sử dụng;
thời kỳ áp dụng chính sách;
căn cứ thuế hiện hành.
Đây là trường hợp phải phân biệt chứng minh có hoạt động phát triển phần mềm với đủ điều kiện hưởng một ưu đãi thuế cụ thể.
Case 4 – doanh nghiệp bán máy kèm phần mềm điều khiển do mình phát triển
Công ty D sản xuất máy kiểm tra linh kiện.
Mỗi máy gồm:
khung máy;
camera;
sensor;
PLC;
máy tính công nghiệp;
phần mềm điều khiển.
Phần mềm do đội kỹ thuật công ty tự phát triển.
Nếu hợp đồng chỉ ghi:
“Máy kiểm tra tự động: 1,2 tỷ đồng”
thì sau này rất khó nhìn thấy cấu phần phần mềm.
Doanh nghiệp cần quản trị riêng:
hardware BOM;
firmware;
application software;
repository;
version;
tài liệu phát triển;
giá trị thương mại từng cấu phần khi có căn cứ bóc tách phù hợp.
Việc phân tách phải phản ánh giao dịch thật, không nên chia giá trị hình thức chỉ để phục vụ một mục tiêu thuế.
Case 5 – công ty phát triển SaaS và thu phí sử dụng hàng tháng
Công ty E tự xây dựng nền tảng quản lý kho.
Công ty sở hữu:
source code;
database architecture;
UI;
thương hiệu;
quyền khai thác.
Khách hàng không mua source code mà trả:
2 triệu đồng/tháng/tài khoản.
Trong thời gian Thông tư 13/2020/TT-BTTTT được áp dụng, nội dung quy trình còn đề cập việc bán, cho thuê, phân phối, phát hành sản phẩm phần mềm tự sản xuất.
Với mô hình SaaS, doanh nghiệp cần lưu hai lớp hồ sơ:
Lớp sản xuất: requirement → design → code → test → release.
Lớp khai thác thương mại: subscription → user → kỳ tính phí → hóa đơn → doanh thu.
Không nên vì sản phẩm không được “bán đứt” mà bỏ qua hồ sơ phát triển.
Hồ sơ “đẹp” nhưng vẫn yếu – những lỗi khiến doanh nghiệp khó chứng minh hoạt động sản xuất phần mềm
Một bộ hồ sơ dày chưa chắc là một bộ hồ sơ tốt.
Điểm quan trọng là tính đồng bộ, tính thời gian và khả năng truy xuất.
Chỉ có hợp đồng và hóa đơn nhưng không có hồ sơ kỹ thuật
Hợp đồng có thể nói:
“Phát triển phần mềm ERP”.
Hóa đơn cũng ghi:
“Phát triển phần mềm ERP”.
Nhưng khi hỏi:
Requirement đâu?
Architecture đâu?
Repository đâu?
Test đâu?
Release đâu?
doanh nghiệp không xuất trình được.
Khi đó, hai chứng từ thương mại chủ yếu chứng minh rằng hai bên có giao dịch, chưa phản ánh đầy đủ việc doanh nghiệp đã thực hiện quá trình kỹ thuật như thế nào.
Có source code nhưng không chứng minh được công đoạn xác định yêu cầu hoặc thiết kế
Đây từng là điểm đặc biệt quan trọng dưới cơ chế Thông tư 13/2020/TT-BTTTT.
Thông tư quy định hoạt động đối với sản phẩm được xác định đáp ứng quy trình khi tổ chức, doanh nghiệp thực hiện ít nhất một trong hai công đoạn: xác định yêu cầu hoặc phân tích và thiết kế.
Do đó, với hồ sơ các kỳ thuộc thời gian văn bản này được áp dụng, repository đầy đủ nhưng chỉ chứng minh coding vẫn có thể chưa giải quyết được câu hỏi cốt lõi.
Ví dụ:
Khách hàng gửi architecture.
Khách hàng gửi database.
Khách hàng gửi specification.
Doanh nghiệp code.
Trong trường hợp đó, Git history chứng minh rất tốt rằng doanh nghiệp đã lập trình, nhưng không tự động chứng minh doanh nghiệp thực hiện requirement hoặc design.
Hồ sơ được lập sau để hợp thức hóa thay vì hình thành trong quá trình làm dự án
Một tài liệu requirement lập tháng 8/2026 nhưng lại ghi rằng nó dùng cho dự án đã nghiệm thu tháng 3/2024 sẽ đặt ra nhiều câu hỏi.
Hồ sơ kỹ thuật mạnh thường có dấu vết thời gian tự nhiên:
email;
commit;
ticket;
meeting record;
version history;
file history;
release;
biên bản nghiệm thu.
Do đó, cách tốt nhất không phải là đợi khi kiểm tra thuế mới “viết lại” toàn bộ tài liệu.
Nên để hồ sơ hình thành song song với quá trình phát triển.
Tài liệu không xác định được sản phẩm cụ thể
Ví dụ doanh nghiệp có tài liệu:
“Software Requirement”.
Nhưng tài liệu không có:
tên sản phẩm;
project code;
version;
khách hàng;
ngày;
người phụ trách.
Sau ba năm, gần như không thể chứng minh nó thuộc dự án nào.
Mỗi tài liệu kỹ thuật nên có metadata tối thiểu:
Product ID | Project ID | Version | Date | Owner | Status.
Tên sản phẩm trong hợp đồng, hóa đơn và hồ sơ kỹ thuật không thống nhất
Ví dụ:
Hợp đồng: Smart Factory System.
Repository: GM-MES.
Biên bản nghiệm thu: Production Dashboard.
Hóa đơn: Dịch vụ lập trình.
Báo cáo dự án: Factory Management Platform.
Có thể tất cả đều là một sản phẩm, nhưng người kiểm tra hồ sơ không có nghĩa vụ tự suy luận điều đó.
Doanh nghiệp nên lập Product Master List để quản lý:
Tên thương mại.
Tên pháp lý.
Tên repository.
Project code.
Version.
Khách hàng.
Hợp đồng liên quan.
Trộn doanh thu phần mềm với thiết bị, tư vấn và dịch vụ khác
Một hợp đồng 3 tỷ đồng có thể gồm:
1,5 tỷ thiết bị.
800 triệu phần mềm.
300 triệu triển khai.
200 triệu đào tạo.
200 triệu bảo trì.
Nếu doanh nghiệp hạch toán toàn bộ 3 tỷ thành “doanh thu phần mềm”, việc giải trình sẽ rất rủi ro.
Ngược lại, nếu mọi thứ đều đưa vào “doanh thu bán thiết bị”, doanh nghiệp cũng mất khả năng nhìn thấy cấu phần phần mềm thực tế.
Nguyên tắc phù hợp hơn là:
Một hợp đồng có nhiều bản chất kinh tế → xác định từng cấu phần có căn cứ → hạch toán và lưu hồ sơ tương ứng.
Từ hồ sơ kỹ thuật đến hồ sơ thuế – doanh nghiệp cần nối dữ liệu như thế nào?
Điểm yếu của nhiều doanh nghiệp công nghệ là phòng kỹ thuật và phòng kế toán vận hành như hai thế giới riêng biệt.
Developer quản lý:
Jira → Git → Release.
Kế toán quản lý:
Contract → Invoice → Revenue.
Trong khi hồ sơ giải trình cần nối được hai chuỗi này.
Xác định từng sản phẩm phần mềm và từng nguồn doanh thu
Doanh nghiệp nên xây danh mục sản phẩm trung tâm.
Ví dụ:
Product ID Sản phẩm Khách hàng Project Nguồn thu
SW01 WMS Nhà máy A WMS-A Development
SW02 MES Nhà máy B MES-B License
SW03 HR SaaS Nhiều KH SaaS-HR Subscription
Từ Product ID có thể truy ngược sang:
hợp đồng;
repository;
SRS;
release;
nghiệm thu;
hóa đơn.
Tách doanh thu sản xuất phần mềm với dịch vụ khác
Doanh nghiệp có thể đồng thời phát sinh:
phát triển sản phẩm;
license;
SaaS;
customization;
implementation;
maintenance;
support;
đào tạo;
tư vấn;
bán server;
bán thiết bị.
Không nên chỉ xây một tài khoản nội bộ mang tên “Doanh thu CNTT”.
Ít nhất ở lớp quản trị, doanh nghiệp nên biết từng đồng doanh thu đến từ loại hoạt động nào.
Việc xác định cách hạch toán và chính sách thuế cụ thể cần tiếp tục đối chiếu quy định thuế đang có hiệu lực tại kỳ tính thuế tương ứng.
Liên kết hợp đồng – nghiệm thu – hóa đơn – tài liệu kỹ thuật
Một project code duy nhất có thể giải quyết phần lớn vấn đề.
Ví dụ:
Project: MES-SAM-26
Hợp đồng: HD-MES-SAM-26.
Requirement: RQ-MES-SAM-26.
Repository: MES-SAM-26.
Release: MES-SAM-26-V1.
Nghiệm thu: NT-MES-SAM-26.
Invoice: INV-MES-SAM-26.
Khi đó kế toán chỉ cần tìm mã dự án để mở được toàn bộ hồ sơ thương mại và kỹ thuật.
Xác định nhân sự trực tiếp tham gia từng dự án
Nhân sự cũng là một lớp chứng cứ quan trọng.
Doanh nghiệp nên có khả năng xác định:
Business Analyst nào phân tích?
Architect nào thiết kế?
Developer nào lập trình?
Tester nào kiểm thử?
PM nào quản lý?
Nhân sự tham gia thời gian nào?
Không nhất thiết mỗi developer phải có một tập hồ sơ giấy riêng.
Có thể sử dụng:
project assignment;
timesheet;
Jira;
Git;
task history;
biên bản họp;
quyết định phân công.
Mục tiêu là chứng minh cấu trúc đội dự án phù hợp với quá trình tạo sản phẩm.
Chuẩn bị hồ sơ trước khi cơ quan thuế yêu cầu giải trình
Đây là nguyên tắc đáng áp dụng nhất.
Đừng đợi đến khi nhận công văn yêu cầu giải trình mới tìm:
developer cũ;
repository cũ;
email cũ;
SRS cũ;
biên bản cũ.
Một Software Evidence Folder nên được đóng sau mỗi release hoặc sau mỗi năm tài chính.
Có thể gồm:
01 – Product Profile
02 – Contract
03 – Requirement
04 – Analysis & Design
05 – Development Evidence
06 – Test
07 – Release
08 – Acceptance
09 – Invoice & Revenue
10 – Personnel
11 – IP Documents.
Về mặt lịch sử pháp lý, Thông tư 13/2020/TT-BTTTT được ban hành để xác định hoạt động sản xuất sản phẩm phần mềm đáp ứng quy trình phục vụ ưu đãi thuế thu nhập doanh nghiệp. Tuy nhiên, nguồn hướng dẫn chính thức của Bộ Khoa học và Công nghệ công bố tháng 6/2026 cho biết Thông tư này đã hết hiệu lực từ ngày 15/12/2025; vì vậy doanh nghiệp đang xử lý kỳ thuế năm 2026 cần kiểm tra căn cứ pháp luật áp dụng tại đúng thời kỳ thay vì mặc nhiên sử dụng Thông tư 13 như văn bản hiện hành.
Checklist tự rà soát hoạt động sản xuất sản phẩm phần mềm tại Bắc Ninh
Doanh nghiệp có thể dùng checklist dưới đây như một vòng kiểm tra trước khi đi sâu vào hồ sơ thuế.
Sản phẩm đã được gọi tên và phân loại rõ chưa?
Có tên sản phẩm cụ thể.
Có Product ID.
Có version.
Có mô tả chức năng.
Xác định người sử dụng.
Xác định khách hàng.
Xác định quyền sở hữu.
Phân biệt sản phẩm với dịch vụ đi kèm.
Nếu doanh nghiệp còn không xác định được mình đang chứng minh sản phẩm nào, các bước tiếp theo gần như không thể thực hiện chắc chắn.
Có căn cứ xác định sản phẩm thuộc Danh mục sản phẩm phần mềm không?
Đã mô tả đầy đủ chức năng sản phẩm.
Đã phân loại nhóm sản phẩm.
Có căn cứ đối chiếu danh mục áp dụng tại thời kỳ cần rà soát.
Sản phẩm lai phần cứng – phần mềm đã được phân tích riêng.
Firmware hoặc embedded software đã được nhận diện rõ.
Không dựa duy nhất vào tên thương mại để phân loại.
Doanh nghiệp thực hiện những công đoạn nào trong 7 công đoạn?
Đối với việc rà soát hồ sơ lịch sử theo Thông tư 13/2020/TT-BTTTT, doanh nghiệp có thể tiếp tục sử dụng bản đồ 7 công đoạn để mapping dự án:
Xác định yêu cầu.
Phân tích và thiết kế.
Lập trình, viết mã lệnh.
Kiểm tra, thử nghiệm.
Hoàn thiện, đóng gói sản phẩm.
Cài đặt, chuyển giao, hướng dẫn, bảo trì.
Phát hành, phân phối sản phẩm.
Quan trọng hơn việc tick “có” là phải trả lời:
Ai làm? Khi nào? Tài liệu nào chứng minh?
Mỗi công đoạn có tài liệu hình thành thực tế để chứng minh không?
Có thể lập bảng:
Công đoạn Có thực hiện? Bằng chứng
Requirement Có SRS, Meeting, Jira
Design Có Architecture, ERD
Coding Có Git
Testing Có Test Case
Release Có Release Note
Deployment Có Deployment Record
Acceptance Có Biên bản nghiệm thu
Một ô “Có” nhưng không có bằng chứng nên được xem là một điểm cần bổ sung hệ thống quản trị.
Hợp đồng, hóa đơn và hồ sơ kỹ thuật có thống nhất không?
Kiểm tra ít nhất:
Tên sản phẩm.
Tên khách hàng.
Project code.
Phạm vi công việc.
Thời gian thực hiện.
Deliverables.
Giá trị.
Nghiệm thu.
Hóa đơn.
Nếu một tài liệu sử dụng tên khác, cần có cơ sở mapping rõ ràng.
Doanh thu phần mềm đã được tách khỏi các hoạt động khác chưa?
Kiểm tra:
Doanh thu phát triển phần mềm.
Doanh thu license/SaaS.
Doanh thu triển khai.
Doanh thu maintenance.
Doanh thu support.
Doanh thu tư vấn.
Doanh thu hardware.
Doanh thu đào tạo.
Tách ở đây không có nghĩa tùy ý chia doanh thu trên sổ sách. Việc phân loại phải có căn cứ từ hợp đồng, giao dịch thực tế, chính sách kế toán và pháp luật thuế áp dụng.
Khi nào doanh nghiệp Bắc Ninh nên rà soát lại toàn bộ hồ sơ phần mềm?
Không cần đợi đến lúc có quyết định kiểm tra mới bắt đầu.
Có một số “điểm kích hoạt” mà doanh nghiệp nên coi là tín hiệu phải audit lại toàn bộ hệ thống.
Trước khi áp dụng chính sách thuế hoặc ưu đãi
Đây là thời điểm bắt buộc phải rà soát kỹ.
Doanh nghiệp cần trả lời riêng ba nhóm câu hỏi:
Nhóm 1 – hoạt động: doanh nghiệp thực sự làm gì?
Nhóm 2 – sản phẩm: doanh nghiệp tạo sản phẩm gì?
Nhóm 3 – chính sách: tại kỳ tính thuế đang xét, văn bản nào điều chỉnh và doanh nghiệp đáp ứng điều kiện nào?
Đặc biệt, không nên tiếp tục dùng máy móc Thông tư 13/2020/TT-BTTTT cho kỳ năm 2026 khi nguồn hướng dẫn của cơ quan quản lý đã xác định văn bản này hết hiệu lực từ ngày 15/12/2025.
Khi bắt đầu có doanh thu phần mềm lớn
Khi doanh thu phần mềm chỉ chiếm 5% tổng doanh thu, nhiều doanh nghiệp chưa chú ý đến hệ thống chứng cứ.
Khi tỷ trọng tăng lên 30%, 50% hoặc trở thành ngành kinh doanh chính, các vấn đề bắt đầu xuất hiện:
Doanh thu nào là phần mềm?
Dự án nào là outsourcing?
Dự án nào là sản phẩm?
SaaS hạch toán thế nào?
Hardware tách thế nào?
Maintenance xử lý ra sao?
Đây là lúc nên xây Software Revenue Map trước khi dữ liệu trở nên quá lớn.
Khi chuyển từ gia công sang phát triển sản phẩm riêng
Một công ty ban đầu có thể chỉ cung cấp developer cho Nhật Bản.
Sau ba năm, công ty tự xây:
WMS;
HRM;
SaaS accounting;
AI inspection.
Khi chuyển mô hình, toàn bộ hệ thống quản trị phải thay đổi.
Gia công thường quản lý theo:
Customer → Project → Man-hour.
Sản phẩm riêng phải quản lý thêm:
Product → IP → Version → Release → Subscription → Customer.
Nếu không thay hệ thống, công ty rất dễ trộn hai mô hình.
Khi doanh nghiệp có cả phần mềm và phần cứng trong cùng dự án
Đây là nhóm rủi ro cao tại Bắc Ninh.
Đặc biệt với:
Smart Factory.
IoT.
Machine Vision.
Automation.
Robot.
Thiết bị điện tử.
Hệ thống kiểm tra.
Một hợp đồng có thể chứa tới 5–7 loại doanh thu.
Doanh nghiệp nên rà trước khi ký hợp đồng, bởi sau khi đã xuất hóa đơn một gói tổng hợp thì việc bóc tách lại sẽ khó hơn nhiều.
Khi chuẩn bị thanh tra, kiểm tra hoặc giải trình thuế
Khi đã xuất hiện yêu cầu giải trình, doanh nghiệp nên chuyển từ “thu thập giấy tờ” sang dựng bản đồ chứng cứ.
Mỗi dòng doanh thu cần trả lời được:
Doanh thu → Invoice → Acceptance → Contract → Product → Project → Requirement → Design → Development → Test → Personnel.
Nếu một mắt xích bị mất, cần xác định ngay:
Mất tài liệu nào?
Có chứng cứ thay thế hợp pháp nào?
Có dữ liệu điện tử nào?
Có email, Git hoặc hệ thống quản lý dự án nào?
Không nên tạo lại tài liệu rồi ghi lùi ngày để lấp khoảng trống hồ sơ.
Dịch vụ xác định hoạt động sản xuất sản phẩm phần mềm tại Bắc Ninh
Đối với doanh nghiệp phần mềm, doanh nghiệp điện tử, doanh nghiệp FDI hoặc nhà cung cấp giải pháp Smart Factory tại Bắc Ninh, việc rà soát hoạt động phần mềm nên được thực hiện đồng thời trên ba lớp: pháp lý – kỹ thuật – kế toán thuế.
Dịch vụ rà soát phù hợp không chỉ trả lời câu hỏi “có phải sản xuất phần mềm hay không”, mà còn phải chỉ ra doanh nghiệp đang thiếu bằng chứng ở đâu và phải tổ chức dữ liệu thế nào để có thể giải trình được từng sản phẩm.
Phân loại sản phẩm phần mềm theo hoạt động thực tế
Bước đầu tiên là lập Product Map.
Mỗi sản phẩm được rà:
Tên sản phẩm.
Chức năng.
Version.
Khách hàng.
Mô hình thương mại.
Quyền sở hữu.
Phần cứng đi kèm.
Dịch vụ đi kèm.
Từ đó mới xác định nhóm sản phẩm và căn cứ pháp lý phù hợp với thời kỳ cần xem xét.
Mapping dự án với 7 công đoạn sản xuất phần mềm
Đối với hồ sơ lịch sử thuộc giai đoạn áp dụng Thông tư 13/2020/TT-BTTTT, từng dự án có thể được mapping với khung 7 công đoạn.
Ví dụ:
Requirement: Có.
Design: Có.
Coding: Có.
Testing: Có.
Release: Có.
Deployment: Có.
Distribution: Không.
Sau đó xác định bằng chứng tương ứng.
Mục tiêu không phải cố tick đủ 7 công đoạn. Yêu cầu cũ của Thông tư 13 cũng không bắt buộc doanh nghiệp phải thực hiện toàn bộ bảy công đoạn mà tập trung vào việc phải có ít nhất công đoạn xác định yêu cầu hoặc phân tích và thiết kế.
Rà soát hợp đồng, nghiệm thu và bộ tài liệu kỹ thuật
Một dự án có thể được kiểm tra theo chuỗi:
Contract → Scope → Deliverables → Requirement → Design → Git → Test → Release → Acceptance → Invoice.
Các điểm không thống nhất sẽ được đánh dấu.
Ví dụ:
Hợp đồng ghi consulting nhưng deliverable là source code.
Invoice ghi software nhưng hợp đồng là bán thiết bị.
Nghiệm thu không ghi version.
Repository không xác định khách hàng.
SRS không có project code.
Đây chính là những điểm cần xử lý trước khi trở thành vấn đề trong hồ sơ giải trình.
Xây checklist chứng minh theo từng sản phẩm, từng dự án
Không nên dùng một checklist duy nhất cho cả công ty.
Mỗi Product ID nên có một bộ kiểm tra:
Product Profile
Legal Classification
Contract
Requirement
Design
Development
Test
Release
Acceptance
Revenue
Personnel
IP
Nhờ vậy, doanh nghiệp có 50 dự án cũng có thể biết chính xác dự án nào đang thiếu tài liệu nào.
Tách hoạt động sản xuất phần mềm với gia công, tư vấn và dịch vụ CNTT
Một công ty công nghệ có thể đồng thời có:
Product Development.
Software Outsourcing.
IT Consulting.
System Integration.
Maintenance.
IT Helpdesk.
Hardware Trading.
SaaS.
License Resale.
Không nên cố đưa tất cả vào một nhóm “phần mềm”.
Việc phân loại đúng giúp doanh nghiệp vừa hạn chế rủi ro thuế vừa nhìn rõ hiệu quả thật của từng mảng kinh doanh.
Chuẩn hóa bộ hồ sơ phục vụ giải trình và rà soát chính sách thuế
Kết quả cuối cùng nên là một Software Evidence Dossier có thể truy xuất được.
Một cấu trúc tham khảo:
01. Hồ sơ pháp lý sản phẩm
02. Product Profile
03. Hợp đồng và phụ lục
04. Requirement
05. Analysis & Design
06. Source Code Evidence
07. Testing
08. Release & Deployment
09. Nghiệm thu
10. Hóa đơn – doanh thu
11. Nhân sự dự án
12. Sở hữu trí tuệ
13. Mapping căn cứ pháp lý theo kỳ tính thuế
Điểm cuối cùng đặc biệt quan trọng đối với hồ sơ năm 2026. Thông tư 13/2020/TT-BTTTT từng quy định trực tiếp việc xác định hoạt động sản xuất sản phẩm phần mềm đáp ứng quy trình để hưởng ưu đãi thuế thu nhập doanh nghiệp. Tuy nhiên, hướng dẫn được Bộ Khoa học và Công nghệ đăng tải trong tháng 6/2026 xác định Thông tư này đã hết hiệu lực từ ngày 15/12/2025.
Vì vậy, nếu doanh nghiệp Bắc Ninh đang rà soát các kỳ thuế trước ngày 15/12/2025, khung hồ sơ và quy trình của Thông tư 13 vẫn là dữ liệu pháp lý quan trọng cần đối chiếu theo đúng thời kỳ. Nếu doanh nghiệp đang xác định chính sách cho năm 2026 trở đi, cần rà soát văn bản pháp luật mới áp dụng tại thời điểm phát sinh thay vì chỉ sao chép bộ tiêu chí cũ.
Dù căn cứ pháp lý thay đổi, nguyên tắc quản trị hồ sơ vẫn không thay đổi: một ưu đãi thuế bền vững phải bắt đầu từ hoạt động thật, sản phẩm thật, doanh thu thật và một chuỗi tài liệu được hình thành trong chính quá trình tạo ra sản phẩm.
Xác định hoạt động sản xuất sản phẩm phần mềm là bước nền tảng giúp doanh nghiệp công nghệ xây dựng mô hình kinh doanh đúng hướng và đảm bảo tuân thủ quy định pháp luật. Việc phân biệt rõ giữa sản xuất sản phẩm phần mềm và các hoạt động dịch vụ công nghệ thông tin khác giúp doanh nghiệp tránh nhầm lẫn trong đăng ký ngành nghề, kê khai thông tin và thực hiện các thủ tục liên quan.
