Mẫu hợp đồng phát triển phần mềm: cấu trúc và cách điền

Mẫu hợp đồng phát triển phần mềm chỉ là khung; giá trị nằm ở cách điền. Bảy ô trống quyết định hợp đồng có dùng được không: phạm vi, tiêu chí nghiệm thu, giá, thời hạn, quyền với mã nguồn, dữ liệu và điều kiện chấm dứt. Điền sai một ô, tranh chấp xuất hiện ở đúng ô đó.

Tóm tắt nhanh

• Mẫu hợp đồng giải quyết phần hình thức; phần rủi ro nằm ở nội dung điền vào.
• Điền theo thứ tự từ phạm vi đến chấm dứt, vì mỗi ô sau phụ thuộc vào ô trước.
• Ô "tiêu chí nghiệm thu" là ô quyết định dòng tiền, không phải ô kỹ thuật.
• Phụ lục phải được đánh số và dẫn chiếu; phụ lục không dẫn chiếu là phụ lục không tồn tại.
• Một hợp đồng dùng được phải đọc hiểu được bởi người không tham gia đàm phán.

Mẫu hợp đồng chỉ giải quyết phần hình thức

Một hợp đồng có hiệu lực cần bốn yếu tố: chủ thể có năng lực, ý chí tự nguyện, nội dung không vi phạm điều cấm, và hình thức phù hợp với loại giao dịch. Mẫu hợp đồng giúp bạn không bỏ sót bốn yếu tố này. Nó không giúp bạn quyết định phạm vi nào là hợp lý, mức giá nào là công bằng, hay rủi ro nào nên do bên nào chịu.

Vì vậy có hai loại mẫu. Loại thứ nhất là mẫu của bên bán, được thiết kế để bảo vệ bên bán. Loại thứ hai là mẫu của bên mua, được thiết kế để bảo vệ bên mua. Dùng nguyên một mẫu mà không sửa là chấp nhận toàn bộ cách phân bổ rủi ro của người viết mẫu.

Cách làm thực tế là chọn một mẫu trung tính, sau đó điền và sửa từng ô theo dự án cụ thể. Việc điền quan trọng hơn việc chọn mẫu, vì hai bên dùng cùng một mẫu vẫn có thể ký hai hợp đồng có rủi ro hoàn toàn khác nhau.

Một lưu ý về giới hạn: hợp đồng là công cụ phân bổ rủi ro, không phải công cụ bảo đảm kết quả. Không có điều khoản nào bảo đảm phần mềm chạy đúng nếu phạm vi không rõ. Vì vậy thứ tự ưu tiên khi soạn là phạm vi, tiêu chí nghiệm thu, rồi mới đến giá và thời hạn.

Điền theo thứ tự nào để không phải sửa lại

Thứ tự điền quan trọng vì các ô sau phụ thuộc vào ô trước. Điền giá trước khi chốt phạm vi là nguyên nhân phổ biến nhất của việc phải đàm phán lại giữa dự án.

Bước 1: phạm vi. Mô tả sản phẩm bàn giao bằng danh từ, không bằng động từ. "Ứng dụng quản lý đơn hàng cho 3 chi nhánh, gồm 8 màn hình" là phạm vi. "Hỗ trợ quản lý đơn hàng" không phải phạm vi.

Bước 2: tiêu chí nghiệm thu. Mỗi hạng mục trong phạm vi cần một tiêu chí kiểm tra được. Tiêu chí phải viết trước khi biết ai làm, để tránh tiêu chí được thiết kế theo năng lực của người thực hiện.

Bước 3: giá và mốc thanh toán. Giá gắn với hạng mục, mốc thanh toán gắn với nghiệm thu. Nếu giá chốt trước phạm vi, mọi thay đổi sau đó đều trở thành tranh chấp.

Bước 4: thời hạn. Thời hạn tính từ điều kiện cụ thể, không tính từ ngày ký. Điều kiện thường là ngày hai bên xác nhận đặc tả và ngày bên mua cung cấp đủ dữ liệu, tài khoản, môi trường.

Bước 5: quyền đối với mã nguồn và tài liệu. Xác định ai sở hữu gì sau bàn giao, ai được dùng lại thành phần nào, và nghĩa vụ bàn giao mã nguồn khi kết thúc.

Bước 6: dữ liệu và bảo mật. Xác định dữ liệu nào bên bán được truy cập, lưu ở đâu, xoá khi nào, và trách nhiệm khi có sự cố.

Bước 7: chấm dứt và thanh lý. Xác định trường hợp nào được dừng, ai trả cho phần đã làm, và hồ sơ nào phải bàn giao khi dừng.

Điền xong bảy bước, đọc lại toàn bộ một lượt để tìm mâu thuẫn. Mâu thuẫn hay gặp nhất là giữa phạm vi và tiêu chí nghiệm thu, hoặc giữa mốc thanh toán và điều kiện bàn giao.

Bảy ô trống quyết định giá trị hợp đồng

Bảng này dùng để rà hợp đồng, không thay thế việc đọc toàn văn. Một hợp đồng có thể điền đủ bảy ô nhưng vẫn mâu thuẫn nếu các ô không tham chiếu nhau.

Điền một điều khoản nghiệm thu từ đầu đến cuối

Đây là ví dụ chi tiết nhất trong bài, vì nghiệm thu là ô quyết định dòng tiền và cũng là ô hay bị viết mơ hồ nhất.

Bản nháp thường gặp: "Bên B bàn giao phần mềm cho bên A. Bên A nghiệm thu trong thời hạn 7 ngày. Nếu không có ý kiến, coi như nghiệm thu."

Bản nháp này có ba lỗ hổng. Không xác định bàn giao cái gì. Không xác định căn cứ để từ chối. Không xác định im lặng có nghĩa là gì trong trường hợp bên A không có người kiểm tra.

Cách điền đủ năm trường:

Đối tượng nghiệm thu: liệt kê hạng mục theo phụ lục số 1, mỗi hạng mục có mã. Ví dụ: "Hạng mục A1 đến A8 theo Phụ lục 01".

Người kiểm tra: ghi chức danh hoặc vai trò, không ghi tên cá nhân, để tránh hợp đồng vô hiệu khi người đó nghỉ việc. Ví dụ: "đại diện có thẩm quyền của bên A và trưởng nhóm dự án của bên B".

Thời hạn và cách tính: ghi số ngày làm việc kể từ thời điểm bàn giao hợp lệ, và định nghĩa bàn giao hợp lệ gồm những gì. Ví dụ: "05 ngày làm việc kể từ khi bên B gửi đủ bộ hồ sơ bàn giao gồm mã nguồn, tài liệu triển khai và bản ghi môi trường thử nghiệm".

Tiêu chí đạt: mỗi hạng mục có tiêu chí kiểm tra được, có dữ liệu đầu vào mẫu. Ví dụ: "tạo được đơn hàng từ 3 kênh, đối chiếu đúng số liệu với bảng tính mẫu tại Phụ lục 02".

Xử lý khi không đạt: phân loại lỗi và thời hạn sửa. Ví dụ: "lỗi chặn luồng chính phải sửa trong 03 ngày làm việc; lỗi giao diện nhỏ ghi nhận vào danh sách và xử lý trong giai đoạn bảo hành".

Cách viết này dài hơn bản nháp khoảng bốn lần, nhưng nó loại bỏ phần lớn tranh chấp về "đã bàn giao hay chưa". Điều đáng chú ý là không có câu nào mang tính kỹ thuật cao; tất cả đều là quyết định quản trị.

Phụ lục: đánh số, phiên bản và cách dẫn chiếu

Hợp đồng phần mềm gần như luôn có phụ lục: đặc tả yêu cầu, danh mục hạng mục, biểu giá, mẫu biên bản. Cách quản lý phụ lục quyết định hợp đồng có còn giá trị sau sáu tháng hay không.

Đánh số theo thứ tự phát sinh. Phụ lục 01 là đặc tả ban đầu, Phụ lục 02 là biểu giá, Phụ lục 03 là thay đổi phạm vi. Không đánh số lại khi thêm phụ lục mới, vì số cũ đã được dẫn chiếu trong các văn bản khác.

Ghi ngày hiệu lực trên từng phụ lục. Một phụ lục không có ngày hiệu lực sẽ tranh chấp với phụ lục khác cùng nội dung. Cách xử lý là ghi rõ: "Phụ lục này thay thế Phụ lục 01 kể từ ngày ký".

Dẫn chiếu hai chiều. Hợp đồng phải liệt kê danh mục phụ lục; mỗi phụ lục phải ghi nó thuộc hợp đồng nào. Phụ lục rời không dẫn chiếu là phụ lục không tồn tại khi tranh chấp.

Giữ một nơi lưu duy nhất. Nếu mỗi bên giữ một bản khác nhau, bản được dùng khi tranh chấp là bản có đủ chữ ký và dấu. Cách phòng ngừa là sau mỗi lần ký, gửi bản scan cho cả hai bên và ghi nhận vào biên bản giao nhận hồ sơ.

Ai điền, ai rà soát, ai ký

Nguyên tắc chung: người hiểu rủi ro nhất phải là người viết điều khoản cho rủi ro đó. Kỹ thuật viết tiêu chí nghiệm thu, kế toán viết điều khoản thanh toán, pháp chế viết điều khoản chấm dứt. Khi một người viết tất cả, hợp đồng thường mạnh ở phần người đó hiểu và yếu ở phần còn lại.

Năm lỗi điền mẫu hay gặp

Để lại ô trống có chủ đích. Hai bên thống nhất miệng rằng "sẽ bổ sung sau". Khi tranh chấp, ô trống được hiểu theo hướng bất lợi cho bên soạn thảo hoặc bên có nghĩa vụ chứng minh.

Dùng cùng một từ cho hai khái niệm. "Bàn giao" vừa có nghĩa là gửi mã nguồn, vừa có nghĩa là chuyển giao quyền sử dụng. Cách sửa là đặt mục định nghĩa ngay đầu hợp đồng và dùng đúng một nghĩa.

Ghi thời hạn theo ngày dương lịch nhưng không loại trừ ngày nghỉ. Kết quả là mốc trễ rơi vào dịp lễ và hai bên tranh nhau về cách tính. Cách sửa là ghi rõ "ngày làm việc" và định nghĩa ngày làm việc.

Không gắn phụ lục với hợp đồng. Đặc tả được gửi qua email, không được ký, không được dẫn chiếu. Khi cần đối chiếu, email không có giá trị tương đương phụ lục đã ký.

Sửa bằng bút trên bản đã ký. Bản sửa tay không có xác nhận của cả hai bên tạo ra hai phiên bản hợp đồng. Cách sửa đúng là ký phụ lục hoặc ký lại bản mới, có ghi rõ thay thế bản cũ.

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

Có nên tải mẫu hợp đồng trên mạng để dùng cho dự án phần mềm không?

Có thể dùng làm khung, nhưng phải rà lại toàn bộ. Mẫu tải trên mạng thường được viết cho giao dịch mua bán hàng hoá, không có các điều khoản đặc thù của phần mềm như nghiệm thu theo hạng mục, sở hữu mã nguồn, xử lý dữ liệu và bảo hành sau bàn giao. Nếu dùng nguyên bản, các điều khoản quan trọng nhất sẽ bị thiếu chứ không phải bị sai.

Hợp đồng phát triển phần mềm có bắt buộc công chứng không?

Thông thường không bắt buộc. Hợp đồng dịch vụ và hợp đồng kinh tế có thể giao kết bằng văn bản, có chữ ký của người có thẩm quyền. Công chứng chỉ cần trong một số trường hợp cụ thể hoặc khi một bên yêu cầu để tăng mức bảo đảm. Điều quan trọng hơn công chứng là khả năng chứng minh nội dung đã thoả thuận, nên hãy giữ đủ phụ lục và biên bản.

Nên ghi giá trọn gói hay giá theo hạng mục?

Giá theo hạng mục phù hợp khi phạm vi có thể chia nhỏ và mỗi hạng mục kiểm tra được. Giá trọn gói phù hợp khi phạm vi rất rõ và ít thay đổi. Trong cả hai trường hợp, cần ghi rõ giá đã bao gồm gì và chưa bao gồm gì, đặc biệt là chi phí bên thứ ba như tên miền, máy chủ, dịch vụ gửi tin, bản quyền thư viện.

Nếu hai bên không thống nhất được tiêu chí nghiệm thu thì làm sao?

Cách thực tế là đưa tiêu chí về dạng kiểm tra được bằng dữ liệu mẫu: một bộ dữ liệu đầu vào, một kết quả mong đợi, một người kiểm tra. Khi vẫn không thống nhất, ghi nhận phần đã thống nhất và tách phần chưa thống nhất thành phụ lục riêng có thời hạn giải quyết. Không nên ký hợp đồng với điều khoản nghiệm thu còn mơ hồ, vì đó là điều khoản quyết định dòng tiền.

Cập nhật và kiểm chứng

Cập nhật tháng 11/2026. Bài viết được rà soát theo các văn bản sau, truy cập ngày 05/11/2026:

• Bộ luật Dân sự số 91/2015/QH13 — vanban.chinhphu.vn
• Luật Thương mại số 36/2005/QH11 — vanban.chinhphu.vn
• Luật Sở hữu trí tuệ số 50/2005/QH11, sửa đổi bởi Luật số 131/2025/QH15 — vanban.chinhphu.vn

Đây không phải tư vấn pháp lý hay tư vấn thuế. Nội dung hợp đồng phụ thuộc vào giao dịch cụ thể; doanh nghiệp nên để người có chuyên môn rà soát trước khi ký.

Bài viết liên quan: hợp đồng dịch vụ phát triển phần mềm, hợp đồng hợp tác phát triển phần mềm, thuế GTGT của phần mềm là bao nhiêu và chi phí phát triển phần mềm.

Nếu bạn cần một phạm vi đủ rõ để điền vào hợp đồng, WinSell xây dựng phần mềm theo yêu cầu theo bốn giai đoạn Khám phá, Đặc tả, Xây dựng, Bàn giao và đo lường — xem dịch vụ của WinSell. Báo giá sau khi chốt phạm vi.