Hello, this is attorney Oh Seung-hyun of Cheongchul Law Firm.

"We paid hundreds of millions of won in development fees and the delivery date has passed. The screens load, but the functions do not work properly. In actual use it is riddled with errors, and people say competing products are far better. Yet the developer insists it has built everything." As outsourced software development contracts surge — AI programs, LLM-based services, workflow automation systems — disputes are increasing in which developers collect the fee while failing to meet the contractual specification.

Two questions arise first in such cases. What does "completion" mean in law, when the developer says it has built the product? And what happens when the court appoints an IT expert to conduct an appraisal? Misunderstanding either answer can cost hundreds of millions of won.

What "completion" means in a software works contract

(1) Partial functionality is not completion

Under the Civil Act, the obligation to pay arises when the contractor (the developer) delivers the completed subject matter to the client. In a software development contract, "completion" means a state satisfying the specification set out in the contract — the definition document and requirements specification — such that the client can actually use it for its intended purpose. The fact that the developer is running a server and can display screens is not completion. Every contractual function must operate properly and without errors.

(2) The Supreme Court: completion requires the client's acceptance

In a 2023 decision the Supreme Court made clear that "delivery" of the subject matter under a software works contract does not end with the physical act of handing over files or access rights. It extends to the client inspecting the subject matter and acknowledging, expressly or impliedly, that it has been completed in accordance with the contract (Supreme Court Decision 2022Da289174, 30 March 2023). In other words, where the client has not signed an acceptance certificate or has objected to the delivery, delivery is not complete and the state of default in performance continues.

Accordingly, where the development contract provides that "the acceptance completion date shall be the date on which the client signs and seals the acceptance certificate," completion itself is not recognised without that signature. However strongly the developer asserts that "the functions have been implemented," it will struggle to establish completion where the client refuses acceptance or continues to identify defects.

When can the contract be terminated

(1) Termination for delay — a demand is required after the deadline passes

Where the contract specifies a delivery date, the developer's failure to deliver a completed product after that date constitutes delay. The client may fix a reasonable period and demand performance, and terminate if performance is not made within that period (Article 544 of the Civil Act). In practice, the demand is usually sent by certified mail stating that "if a completed product meeting the specification is not delivered within [X] days, the contract will be terminated."

(2) Termination for refusal to perform — immediate, without demand

Where the developer clearly indicates that it has neither the intention nor the ability to perform, the contract may be terminated immediately without a separate demand (by analogous application of the proviso to Article 544, per Supreme Court precedent). Conduct such as the developer instead applying to a dispute mediation body claiming that "the client is not paying," or allowing more than 15 days to pass without any response to the client's certified mail, may be recognised as a manifestation of refusal to perform. Once refusal is established, the client may give notice of termination immediately, regardless of the delivery date.

How appraisal works in IT development disputes

(1) Percentage-of-completion appraisal — beware the trap

Courts sometimes ask an IT expert appraiser "what percentage complete is this program?" This approach conceals a significant trap. The developer will argue that "completion is 80%, so only a proportionate part of the fee need be refunded." That reasoning is wrong. Unlike construction, software cannot be physically divided into completed portions, and so long as it falls short of the contractual completion standard it remains incomplete. Incomplete software has not been delivered to the client.

(2) A key precedent: full refund despite 61% completion (Seoul Central District Court 2017Gahap560201)

One important decision addresses this squarely. In a software development contract case, the Seoul Central District Court ordered termination and a full refund of the development fees received, even though the court-appointed IT appraiser assessed the program as 61% complete, on the ground that the contractual completion requirement — the client's inspection and approval — had not been satisfied (Seoul Central District Court Decision 2017Gahap560201, 18 October 2019). Even where an appraiser finds 61% built, the client can recover the entire fee if the contractual completion requirement is unmet. Not a proportionate refund, but a full one.

(3) Framing the appraisal is critical — "identity" may matter more than completion

Where there are indications that the developer has sold the client's program to third parties without authorisation or reused it in a similar service, an appraisal of the identity of the two programs becomes far more important than a percentage-of-completion appraisal. If the source code, database and core algorithms of the program developed at the client's request are substantially identical to another of the developer's products, this may constitute both breach of contract and copyright infringement. An identity appraisal compares the source code and configuration management history — Git commit logs and the like — of the two systems.

(4) Who must apply for the appraisal and bear the cost

The burden of proving completion and delivery rests on the developer asserting completion (Supreme Court Decision 2014Da36702, 36719, 24 June 2015). In principle, therefore, it is the developer that must apply to the court for an IT appraisal and deposit the fee. The client has no obligation, nor any practical benefit, in applying first. Where the source code and system exist only on the developer's servers — with no deliverable in the client's hands — the client structurally cannot even apply, having no subject matter to appraise. In that situation an appraisal becomes possible only once the court, on an application for an order to produce documents, orders production of the source code and configuration management history.

Order to produce documents — an essential step before appraisal

Where the developer (as defendant) does not produce source code, the configuration management repository (Git, SVN and the like), bug reports or test results, the client may apply to the court for an order to produce documents (Article 347 of the Civil Procedure Act). If the court so orders and the developer does not comply, the court may accept the client's assertions as established (Article 349). Configuration management history is especially valuable: it records the date, author and content of each change to the source code, providing objective evidence of "how far development had actually progressed when the deadline passed."

Practical checkpoints

• Where the contract provides that "the acceptance completion date shall be the date the client signs and seals the acceptance certificate," completion is not recognised in law without that signature. That clause is your shield, however strongly the developer asserts completion.

• Errors and defects found during testing must be recorded. Whether in a messaging thread, email or a formal feedback system, the date and the nature of the error must survive in writing to be usable as evidence later. Oral complaints are difficult to prove.

• If the developer fails to deliver a completed product after the deadline, immediately serve certified mail stating "the contract will be terminated unless delivery is made within [X] days." At the appraisal or litigation stage, the presence or absence of that notice determines whether termination was lawful.

• Be wary of the argument that "the appraisal shows 61% completion, so only 39% need be refunded." Without the client's acceptance the work is incomplete, and proportionate refund by percentage is not the governing principle (Seoul Central District Court Decision 2017Gahap560201, 18 October 2019).

• If there are indications that the developer is secretly selling the program built at your request to third parties or reusing it in a similar service, this constitutes breach of contract and copyright infringement and can be claimed separately. In that case, pursue an identity appraisal of the two programs and secure the developer's internal contracts, sales materials and call records as evidence.

• If the developer will not produce the source code, apply to the court for an order to produce documents. If the developer fails to comply, your assertions may be accepted as established — refusal to produce source code and configuration history is itself a basis for adverse inference.

• AI and LLM-based software often carries special contractual criteria beyond whether a function is implemented: the completeness of data training, the accuracy of API integration, response accuracy rates. Turning each criterion in the definition document and requirements specification into a checklist, and recording which items are unmet, is of great assistance in litigation.

"We can show you directly — would you like to log in?" When a developer says this and the screen appears, it feels like completion. The law sees it differently. Without an acceptance certificate the client has understood and signed, an open screen is not completion. If you paid hundreds of millions of won in development fees and the functions promised in the contract were never implemented, there is a legal structure through which you can recover the entire amount, whatever the appraisal concludes.