← Вернуться к списку постов

Automation of Contract Work: Creating a Contract Generator with a Protocol of Disagreements in Botman.one

Статья | 23 January 2026

In modern legal practice, time is a valuable resource. Routine operations of preparing and agreeing on standard contracts take hours that could be devoted to complex legal tasks. This article breaks down how to use the Botman.one low-code platform to create an intelligent contract generator. This tool will not only allow clients to customize terms independently but also automatically generate a legally correct protocol of disagreements if the client's proposed changes are not accepted. We will examine in detail the legal nature of this document, the process of its preparation, and the full cycle of its automation in electronic document interchange (EDI).

1. The Legal Essence and Purpose of a Protocol of Disagreements

A protocol of disagreements is a document drawn up by one party when they disagree with certain terms of a draft contract. From a legal standpoint, it represents an acceptance of an offer on different terms (Article 443 of the Civil Code of the Russian Federation). By sending a protocol, a party essentially states: "I am ready to conclude the contract, but only with these amendments." This means that after the protocol is signed by both parties, the disputed clauses of the contract will be executed precisely in the version set out in the protocol.

What is a protocol of disagreements needed for? Its use is critical in several cases:

  • When concluding contracts obligatory for one party: These include public contracts (e.g., retail sale contracts, utility service contracts), contracts with a monopolist, or contracts arising from a preliminary agreement.

  • Within the framework of state and municipal procurement under 44-FZ: The winner of an electronic auction has the right to send a protocol to the customer once to correct errors in details or discrepancies between the draft contract and the procurement documentation. It is important to remember that essential terms (price, term, subject) cannot be changed via a protocol.

  • In everyday contract work: It is an effective tool for fixing a negotiation position, speeding up agreement with a counterparty, and protecting the interests of a party when working with standard adhesion contracts.

It is necessary to distinguish a protocol of disagreements from related documents:

  • An addendum is concluded to an already effective contract.

  • A protocol of settlement (reconciliation) of disagreements is drawn up in response to a received protocol of disagreements and contains counter-proposals. Parties can exchange these documents until an acceptable version is developed.

2. How a Protocol of Disagreements is Drafted: Structure and Practical Recommendations

The law does not establish a strict form for the protocol, but a generally accepted practice for its preparation has been developed.

Recommended document structure:

  1. Header: Indicates the name ("Protocol of Disagreements No. ..."), reference to the number and date of the draft contract, full details of the parties.

  2. Preamble: Statement of the fact of disagreements and intention to settle them.

  3. Main part (in table form): This is the heart of the document. The table should be as clear as possible.

    Clause No. of the contract Version proposed in the draft contract Proposed version (your variant) Justification for changes (if necessary)
    4.1. "Payment is made within 5 banking days from the date of signing the contract." "Payment is made within 10 banking days from the date the Customer receives the invoice." To comply with the internal regulations of the Customer's finance department.
    7.3. "The penalty for late delivery is 0.01% of the goods' value for each day of delay." "The penalty for late delivery is 0.1% of the value of the goods not delivered on time for each day of delay." Corresponds to established practice and is proportionate to the breach.

  4. Concluding part: States that the protocol is an integral part of the contract, and in case of discrepancy between terms, the terms of the protocol take precedence. Also, the number of copies is recorded.

  5. Signatures and seals of the parties.

Key drafting principles:

  • Clarity and specificity. Avoid formulations like "review", "clarify". Offer a ready, legally verified version.

  • Justification. A brief explanation of the reason for changes (reference to a legal norm, internal regulation) increases the chances of the counterparty's agreement.

  • Compliance with deadlines. As a general rule, for civil law contracts, the protocol is sent within 30 days of receiving the draft. In procurement under 44-FZ, the deadline is strict — 5 working days from receiving the draft contract from the customer. Missing the deadline deprives one of the opportunity to send a protocol.

3. Full Automation Cycle: From Client Request to Signed Protocol in EDI

Here's how to build an end-to-end automated process using Botman.one.

Stage 1: Creating an Interactive Contract Generator

You set up a template of your standard contract with dynamic fields in Botman.one. Then you create a public form (e.g., on the company website or in a chatbot) where the client fills in:

  • Their details (INN/OGRN — for automatic verification via DaData API).

  • Key parameters: terms, cost, special conditions.

  • Important block: proposals for changing standard clauses. For example, the client can select an alternative wording for payment or liability from a drop-down list.

Stage 2: Automatic Generation of a Document Package

After filling out the form, the script in Botman.one follows two branches:

  • If the client's amendments fall within pre-approved options: The system generates a final contract with the changes already incorporated and sends it for signing.

  • If the client proposes non-standard amendments: The system automatically creates two documents:

    1. A draft contract in your original version.

    2. A protocol of disagreements, where the contract clauses and the version proposed by the client are reflected in tabular form. Documents are generated instantly, without lawyer involvement.

Stage 3: Integration into Electronic Document Interchange (EDI) Systems and 1C

The generated documents need to be sent for signing and accounted for.

  • Sending the protocol of disagreements to SBIS, Diadoc, etc.: Botman.one can transmit ready files (PDF, DOCX) directly to your EDI system via API for sending to the counterparty.

  • Critical nuance of signing in EDI: When signing a contract to which there is a protocol, the electronic signature must include a comment/mark "With protocol of disagreements." This is the electronic equivalent of the corresponding note on paper and a legally significant action that prevents the contract from being considered unconditionally accepted.

  • Processing the protocol of disagreements in 1C: Many use "1C:Document Flow" for internal approval. In this system, you can set up a process where unagreed remarks are automatically formed into a draft protocol. Botman.one can act as an initial generator and then transfer data (details, essence of disagreements) to 1C for further internal workflow and archiving.

Stage 4: Working with the Counterparty's Response

Having received a contract signed by the client with the note and the protocol, you make a decision:

  • Agree with the amendments: You sign the protocol of disagreements with your electronic signature. From this moment, the contract is considered concluded in the version of the protocol.

  • Do not agree: You send the client a protocol of settlement of disagreements with your counter-edition. Its template can also be prepared automatically in Botman.one.

4. Ready-Made Protocol of Disagreements Template for Automation

For use in the Botman.one generator, prepare a text template in the following format (fields for auto-substitution are marked, for example, as {variable}):

PROTOCOL OF DISAGREEMENTS No. {protocol_number}
to the draft {contract_type} agreement No. {contract_number} dated "{contract_date}"

City {City} "{Date}"

{Full name of Legal Entity 1}, hereinafter referred to as "Party 1", represented by {position, full name}, acting on the basis of {Charter/Power of Attorney}, on the one hand, and
{Full name of Legal Entity 2}, hereinafter referred to as "Party 2", represented by {position, full name}, acting on the basis of {Charter/Power of Attorney}, on the other hand,
hereinafter collectively referred to as the "Parties", have drawn up this Protocol as follows:

  1. During the review of the draft agreement by Party 2, the following disagreements were identified.

  2. The Parties have agreed on the following version of the disputed terms:

Clause No. of the contract Version of Party 1 (according to the draft) Version of Party 2 (proposed)
{clause_1} {original_text_1} {client_amendment_text_1}
{clause_2} {original_text_2} {client_amendment_text_2}

  1. This Protocol is an integral part of the aforementioned agreement.

  2. In case of discrepancy between the terms of the agreement and this Protocol, the terms of the Protocol shall prevail.

  3. The Protocol is drawn up in two copies, each having equal legal force, one for each Party.

SIGNATURES OF THE PARTIES:

Party 1: Party 2:
{Position} {Position}
________________/ {Full name} ________________/ {Full name}
Seal Seal

Conclusion

Automating the preparation of a protocol of disagreements via Botman.one is not just a technical optimization. It is a transition to a qualitatively new level of contract work. You minimize routine errors, speed up the agreement process several times over, and provide clients with a modern service. At the same time, the lawyer retains control over complex amendments, freeing up time for analytics and strategy. Implementing such a solution is a direct contribution to the digital transformation of the legal department, increasing its efficiency and significance within the company.