Electronic Document Management Rules: Statuses, Roles, Deadlines

Why set the rules first, then automate

Automation amplifies what already exists. If rules aren’t agreed, the system simply makes the chaos happen faster: documents go to the wrong people, get stuck “somewhere,” and arguments about what “in approval” means turn into daily threads.

Without a regulation for electronic document management, three things usually break: clear statuses, responsibility and deadlines. As a result, people start bypassing the system: sending files by email, duplicating tasks in messengers and asking to “get a signature urgently,” because it’s unclear who should act and by when.

Imagine a contract marked “approved.” For lawyers it means risks were reviewed. For finance: budget confirmed. For a manager: ready to sign. If these meanings aren’t fixed in advance, every case becomes a dispute and the document goes back to the start. The same goes for roles: if it’s not defined who owns the document and who can send it back for revision, the system keeps prompting questions instead of actions.

Before implementation, decide these things on paper and approve them as one set of rules: which statuses exist and what each means; who can change a status and in what cases; who is responsible for content and who for deadlines and control; what timelines are normal and which are urgent; what happens when a deadline is missed (escalation).

The hardest part is getting divisions to agree. A simple method helps: gather process representatives and agree rules using a real document example. For example, at a company like GSE.kz a supply contract goes through legal, finance, procurement and a manager. If each confirms their steps and deadlines in advance, automation won’t meet resistance later.

To reach unified rules, a short agreement is usually enough: one process owner records the final version; status definitions are unified and unambiguous; substitution for leave/business trips is configured in advance; there is one clear rule about silence (for example, “no response is not approval” — or the opposite, but consistent for everyone).

When the regulation is ready, automation becomes configuring routes and notifications rather than endless debates about “what’s correct.”

Define scope: which documents and processes to automate

Before writing EDM regulations and choosing a system, agree on the scope. If the scope is vague, automation just cements chaos: some people will work in the EDM system, others by email, and disputed cases will multiply.

Start with the list of documents that will give the most benefit in the first month: those with many approvals, clear risks and identifiable process owners. Usually these are contracts, invoices and acts, internal memos for procurement, payment requests, and routine HR orders. Choose no more than a few types so the team can refine statuses, roles and deadlines.

Initially, postpone documents with too many exceptions or without a clear decision-maker. Often these are one-off free-form letters, rare commissions, complex legal cases, or processes that heavily depend on external partners and lack stable templates.

For each document type, fix three things so scope is unambiguous: who initiates (creates and starts), who approves and who completes the process (signs, registers, archives). For example, in a company supplying equipment to public and corporate customers, a contract can be initiated by a sales manager, approved by legal and finance, and completed by a signing manager and a records manager responsible for registration.

Also list critical requirements that must be met before launch: whether legal significance is needed and which type of signature applies; where and how long to store the document and who is responsible for the archive; mandatory checks (limits, requisites, completeness); how control works (who sees overdue items and what counts as a breach); which data must be included in reporting (for audit purposes).

With a clear scope, it’s easier to discuss routes and deadlines: you automate specific processes, not “all documents at once.”

Document statuses: keep them simple and unambiguous

Most confusion in EDM regulations comes from statuses. A good set of statuses is short, understandable to anyone and works consistently across document types. Too many statuses make people guess which to choose and the process breaks.

It’s important to distinguish status from action. “Sign” is an action (what needs to be done). “Signed” is a status (what happened). In the regulation, define statuses as the document’s state and leave actions for tasks and notifications.

Here is a minimal set that usually suffices for contracts, requests, orders and memos:

• Draft: the document is created and edited by the author. Entry: created. Exit: sent for approval.
• In approval: the document is with approvers. Entry: author sent it. Exit: approved or returned.
• For signing: the document is with the signer. Entry: all approvals obtained. Exit: signed or rejected.
• Returned for revision: there are comments. Entry: someone returned it. Exit: corrected and resent for approval or closed.
• Rejected: the document will not be accepted. Entry: rejection by an approver or signer. Exit: final with reason.
• Signed: signature placed, version fixed. Entry: signer signed. Exit: execution or archive.
• Executed: obligations fulfilled (if applicable). Entry: signed. Exit: archive.
• Archive: final storage, read-only.

To avoid different interpretations, define entry and exit conditions for each status in one sentence. For example: “For signing — the document is approved by all mandatory roles, changes are prohibited, only technical edits allowed by agreement with the author.”

Return for revision and rejection should be recorded with a reason. Usually 5–7 standard reasons are enough (incorrect requisites, no budget, contractual risk, missing attachments) plus a comment field. This reduces disputes and later helps improve templates and requirements.

Roles and responsibilities: who is accountable for what

For EDM regulations to work, roles must be described so each action has a single owner. If a role isn’t defined, people pass checks around and the process stalls.

Initiator (author) is responsible for the quality of initial data. Before sending, they fill required fields, attach correct file versions and confirm the document is ready for review, not for ad-hoc edits. A practical rule: the author is responsible for content, completeness and correct requisites, but not legal subtleties unless they are a lawyer.

Approver checks only items in their area. The accountant looks at amounts, VAT and budget; security checks security requirements; lawyer checks risks and formulations. The regulation should explicitly state that approvers aren’t required to recheck other areas. Otherwise everyone will try to “check everything” and deadlines will slip.

Approver (approving manager) and signer can be the same person, but not always. The approver decides “yes/no,” while the signer signs on behalf of the organization and is responsible for formal issuance. If they are different, define who makes the final edit before signing and who can send the document back for revision.

Secretary or records manager registers the document, checks completeness and correct requisites (number, date, counterparty), and ensures all required files are attached. They do not change content but return the document to the author with a clear reason.

Executor closes the task related to the document (for example, sent to the counterparty, dispatched, archived), and controller records completion and timing. This separates “did the work” from “checked that it was done.”

System administrator is a special role. Changes that alter workflows — creating roles, changing routes, access rights, templates and mandatory fields — should go through them. Otherwise any accidental edit can break the process for everyone.

Mini example: the author prepares a contract and attaches a specification; the lawyer approves terms and risks, the finance person approves payment and limits; the approver gives the go-ahead, the signer signs; the records manager registers and sends it; the executor receives the signed copy from the counterparty, the controller closes the task and records the date.

Approval routes and the responsibility matrix

A route answers the simple question: who and in what order should make a decision. If this isn’t fixed, automation only speeds up chaos: the document will “wander” and the question “who should approve?” becomes daily.

A convenient way to record routes is a responsibility matrix: rows are document types (contract, act, internal memo), columns are divisions and positions, and cells show the role in the process (initiator, approver, reviewer, approver, executor). Distinguish between “position” and “role”: the same manager may be an approver for contracts and only a reviewer for purchase requests.

To make the matrix work, agree in advance on a few rules. Who appoints approvers: for example, only the process owner or a department head, not any initiator. Who and when can change the route: for defined reasons (amount change, change of subject, new risk). How to handle multiple approvers: in parallel (for independent checks) or sequentially (if the next approver depends on the previous edits). How substitution for leave and sick leave is arranged: who appoints a deputy, when auto-substitution triggers, what to do if the deputy lacks rights. And where the final route is recorded: in the regulation and the role directory, not in chat.

Parallel approval typically suits legal, security and IT: they check different aspects. Sequential approval is used where order matters, e.g. “initiator -> financial controller -> manager.” System integrators, including GSE.kz, often ask to choose this principle per document type at the start, otherwise deadlines will be calculated incorrectly.

Also address conflicts of interest: signs are simple — the approver is the initiator or direct beneficiary; approver reports to the initiator with no independent check; one person both reviews and approves risky terms; a participant has ties to the counterparty.

The regulation should state what happens then: mandatory involvement of an independent role (e.g. compliance or security), prohibition on self-approval and a clear procedure to replace an approver without manual negotiations.

Deadlines, control and escalation: keep the process moving

Deadlines in EDM should be measurable. It’s better to set them in working days (or hours for short tasks) and tie them to specific steps: review, approval, signing, registration. Then the regulation becomes a set of clear rules, not just “discipline.”

Separate “time to decide” and “time waiting.” A pause is acceptable when data is missing, clarification from a counterparty is needed, or attachments are absent. But a pause must be recorded with a separate status (for example, “Waiting for data”) and have an owner responsible for the request and follow-up.

For overdue items, define in advance what happens automatically and what a manager does. A simple control ladder works: reminder to the performer N hours before the deadline and at the moment of overdue; notify the initiator so they see deadline risk; escalate to the approver’s manager on the next working day; auto-redirect to the deputy if the person is on leave or unavailable; record the reason for delay (select from a list) to improve the process later.

Also specify urgent documents and exceptions. Urgency must not break the rules, otherwise it becomes a loophole. Usually one clear criterion is enough (for example, “must be signed before the delivery date”) plus a requirement to state reason and deadline.

Don’t forget revisions. Time for revision should be separate and shorter than the main deadline, and re-approval often follows a shortened route (only roles whose comments are actually affected).

Example: for equipment procurement (e.g. servers) a contract returned with legal comments. If the regulation gives 2 working days for revision and 1 day for re-approval, the document won’t wander for weeks and delays become visible and escalated.

Step-by-step: how to approve statuses, roles and deadlines before implementation

To prevent automation from turning into endless edits, first agree on the rules. EDM regulations must answer three questions: what status the document is in, who is responsible now and how much time they have.

Minimal work plan

Start with facts, not theory. Take several recent documents (5–10 from the last month) and trace their path from creation to archive. This quickly shows where extra loops are and where “everything depends on one person.”

A practical order of actions looks like this: collect real examples and mark where they got stuck by dates and messages; draw the current route (who creates, checks, approves, signs, sends and stores); reduce statuses to a simple unambiguous set (for example, replace three variants of “under review” with one); assign roles and a process owner (who changes rules and ensures compliance); fix deadlines for each step, escalation and substitution rules.

How to formalize agreements

After discussions, produce the regulation as a single document: statuses, roles, deadlines, checkpoints and exceptions (for example, “urgent” contracts). Then approve it like any other document so the regulation has authority.

Before final approval, check four things. Any status must be clear: how it ends and who moves the document forward. Each role must have a substitute and clear signing/approval rights. Deadlines must be realistic (not “1 day for everything”) and include a clear escalation trigger. And there should be no hidden approvers who appear “by phone call.”

Only after this move the rules into the system. Otherwise you automate the dispute about “what’s correct.”

Common mistakes when preparing EDM regulations

The most common problem is writing EDM regulations from impressions, not as a set of simple rules everyone understands the same way. Automation then only cements chaos: statuses get mixed up, deadlines are missed and disputed cases are handled manually.

A typical trap is mixing document status and process outcome. For example, “approved” and “signed” may look the same but are different events: approval can be an internal decision while signature is a legal fact (and may occur later). If you don’t separate them, a document might be considered “ready” even though it can’t be sent to a counterparty or used to start procurement.

Second mistake — no process owner. When no one is responsible for rules as a whole, the approval route changes “as agreed this time.” Today a lawyer checks one version, tomorrow asks for another, and finance adds an extra step because “it’s safer.”

Next is vague checking criteria. An approver treats their role as “check everything” rather than a specific review. Then endless edits for style, wording disputes and delays appear. In companies at the level of GSE.kz this is especially visible in contracts and requests where it’s important to quickly separate legal risks, budget limits and technical parameters.

Another frequent issue: deadlines exist, but there’s no escalation, substitution or clear rule for someone on leave. Then the document simply stalls.

To reduce risks, verify basics: separate statuses (where the document is) from results (what happened to it); assign a process owner and a rule-change procedure; for each role record checking criteria and typical return reasons; add escalation and substitution and a clear overdue threshold; limit exceptions — if a rule can’t be applied uniformly, it’s usually unnecessary.

When these errors are removed, the regulation becomes a working tool, not a checkbox document.

Quick check before launching automation

Before moving a process into the system, do a short “viability” check. If EDM regulations don’t pass this test, automation will lock in chaos: documents will circle, deadlines will drift and responsibility will become disputed.

First, make sure you know exactly what you will automate first. Don’t try to cover everything at once: choose a few most frequent and painful document types and bring them to clear rules.

Before launch, close the minimal set of questions: which document types are in the first phase and their priority (by risk and frequency); which statuses are used, what each means and who can change them; which roles participate (initiator, drafter, approver, lawyer, finance control, signer) and where responsibility boundaries lie; what deadlines apply at each step including revision and re-approval; what happens if a deadline fails (escalation, substitution for leave, rules for “urgent yesterday”).

Then check that the rules match reality. For this, 2–3 live cases are enough, but they should be different: one simple, one conflictual, one urgent.

Mini-test with real cases

Take a contract with counterparty edits, an internal purchase memo and an act that must be closed by month-end. Run each case through the route and ask the team: where does the document usually get stuck, which statuses cause disputes, who decides in gray areas.

If you find disputed points, record changes immediately. It’s better to change status definitions and deadlines now than to later “heal” the system with exceptions and manual workarounds.

Final go/no-go signal

Start when any process participant can answer in 30 seconds: what I do, in what time, what status I set and what happens if I miss the deadline.

Example scenario: approving a contract without unnecessary disputes

Imagine a typical case: procurement prepares a contract for equipment supply (for example, servers to update infrastructure). The goal is simple: approve quickly without the “who must edit this?” exchanges.

Roles are fixed in advance and don’t change mid-process. Initiator (procurement) is responsible for content and gathering inputs; lawyer for terms and risks; finance for budget and payment; manager for final decision; records manager for version control, correct formatting and storage.

To avoid arguments about the contract’s current state, it moves through clear statuses:

• Draft (initiator prepares and attaches justification)
• In approval (document with one or more approvers)
• In revision (returned to initiator with comments)
• Approved (all mandatory approvers confirmed)
• Signed (signatures obtained)
• Archive (records manager closes the card and stores the set)

Deadlines are set the same and in advance: each approver — 1–2 working days. If the deadline passes, the system marks it “overdue” and escalates to the approver’s manager. Also decide in advance what counts as a justified pause (e.g. waiting for a counterparty reply) and how to mark it.

Comments are recorded in one place: version comment or a “comments” field where each item has an author, date and status “accepted/rejected/need meeting.” Only the initiator edits text; approvers either accept the version or return it for revision.

Approval is complete when all mandatory roles have given “approved,” there are no open comments and the final version that goes to signing is fixed.

Next steps: pilot, rollout and support

After you approve statuses, roles and deadlines, don’t try to automate everything at once. It’s faster and safer to start with a pilot: you’ll see where the regulation works and where it needs tweaking while changes are still inexpensive.

Choose 1–2 processes that deliver noticeable value and are understandable to participants, for example contract approval or a purchase request. Fix the regulation in a final version: which statuses are used, who moves documents between them, what deadlines apply and what counts as a breach.

To prevent pilot failure from small issues, prepare a minimum for start. You need document templates and mandatory fields (number, counterparty, amount, responsible, validity), unified file and card naming rules, a list of exceptions (what to do if urgent, if data is missing, if staff is on leave), and storage and access requirements (who sees drafts and final versions).

Decide on infrastructure separately: cloud or on-prem. On-prem is often chosen when access control, security requirements and predictable integrations with internal systems matter. Pre-evaluate load, backup and failover for this option.

Training is better planned by roles, not “one-size-fits-all.” Initiators need rules for filling cards and handling comments; approvers — how to make and record decisions; administrators — how to manage routes and rights.

Include support in the rollout plan: who answers user questions, who changes routes, who monitors deadlines and reports. If you need help with infrastructure and implementation, this can be discussed with GSE.kz (gse.kz) as a system integrator: from building solutions to 24/7 technical support and selecting S200 Series servers and workstations for your scale.