Electronic Forms and Approval Workflow Systems: From Paper and Chat to an Auditable Trail

The trouble with paper approvals is not only that they are slow. Slow is manageable. The genuinely awkward part arrives when something goes wrong — a client disputes a discount, accounting cannot reconcile an expense, a manager says they never saw the form — and nobody can find the original record.

Switching to a messaging app looks like progress, but it mostly relocates the same problem. Messages scroll away, a one-word “OK” may or may not count as approval, and the approval record sits in a personal account that disappears when that person leaves.

What an electronic form and approval system buys you is not just speed. It is that every decision has a named person, a time, and a basis behind it, and all of it can be found later.

The real cost of paper and chat-group approvals

These costs never appear in any report, but they are real:

• Waiting. Nobody knows whose desk the form is sitting on, so the requester has to ask their way along the chain. When a manager travels or takes leave, the flow simply stops, because there is no formal delegate mechanism.
• Version confusion. An edited form gets reprinted, attachments are emailed separately, and the discussion happens somewhere else entirely, so the copy that ends up filed may not be the final one.
• Difficult verification. Reconstructing what happened for an audit, a customer complaint, or an internal dispute means digging through paper or scrolling back through messages.
• Permissions drift. Who can approve what, and up to what level, tends to run on shared assumption rather than rules. After a personnel change it becomes even easier for something to be approved by the wrong person or skipped entirely.
• Data that cannot be reused. Numbers on paper cannot be aggregated, so answering “what did we requisition this quarter” means adding it up by hand.

The signal for change is straightforward: if you have ever spent time chasing down who approved something, the current method is already generating cost. This is the same logic that applies to internal admin systems generally — the time spent on manual patching keeps climbing.

Map the process before choosing a system

The most common failure is picking software or commissioning development before mapping the process. The result is that the existing confusion moves into the system untouched, adding a layer of data entry without solving anything.

For each form, mapping should answer at least these questions:

1. Who initiates it. Which role, and in what circumstances the form gets used.
2. What gets filled in. Which fields are required, which are optional, and which can be populated automatically from data you already hold.
3. Who signs, and in what order. Line manager, department head, finance, general manager — and the conditions under which each needs to appear at all.
4. Conditional branches. Value bands, item categories, and whether the request crosses departments all change the route.
5. How exceptions are handled. Urgent items, forms submitted after the fact, an absent manager, a requester who is also the approver.
6. What happens at the end. Is approval the end of it, or does it trigger something downstream such as a purchase, a payment, or a shift assignment?

The mapping exercise has value in itself. Picture a company mapping its requisition flow and discovering that the same category of goods has two separate approval routes, each in use for years, with neither side aware of the other. That kind of discovery only happens when somebody is forced to draw the process out.

Only after mapping can you judge what to build it with. The forms with simple routes and few fields are usually fastest to stand up on an off-the-shelf form tool or a low-code platform; when conditional branching, audit requirements, or integration start hitting the ceiling, that part gets pulled out and built properly. What that “start on a platform, extract when you hit the wall” path costs is covered more fully in A Guide to Low-Code and No-Code Platforms.

Write the results up before handing them to development; structure the document the way How to Write Software Requirements sets out.

What an electronic form needs

Forms look simple, but a few design points determine whether one stays usable.

Field types must be explicit. Dates use a date picker, amounts use a numeric input, departments use a dropdown. Making everything a free-text box is the main reason data later cannot be aggregated or validated.

Populate what you already know. The requester’s department, job title, and manager are already in the system and should not have to be retyped. Retyping wastes time and manufactures inconsistency.

Attachments and notes. Quotations, photos, and scanned contracts need to be attached to the form itself, not sent separately by email.

Drafts and withdrawal. Saving a draft before submission, and withdrawing a submission that has not yet been approved, between them remove most of the friction caused by sending something by mistake.

Form versioning. When the layout of a form changes, previously approved records must still display as they were. A field change should not make historical records unreadable.

Usable on a phone. Managers mostly approve things while out of the office. If the phone experience is poor, the flow will drift back into the chat groups.

How flexible the routing should be

This is the hardest part of the system to judge. Too little flexibility and every exception needs a manual workaround; too much and the configuration becomes so complex that nobody maintains it.

A practical way to layer it:

Layer one: fixed routes. Most forms really are “requester to line manager, done.” Get that simplest case solid first.

Layer two: conditional branches. Adding an approver based on a value band, item category, or department. This is the most common requirement, and it should be designed so administrators can adjust the conditions themselves rather than calling an engineer every time a rule changes.

Layer three: dynamic steps. Rules such as “add the counterpart manager when the request crosses departments” or “add legal for this category.” Complexity starts here, so confirm the need is real before building it.

A few mechanisms are used by almost every company:

• Delegates. Who acts for a manager on leave, with the delegation recorded in the trail. Never let this happen through a shared account.
• Added approvers and returns. An approver can ask for more information and send the form back; whether a resubmission restarts the route from the beginning is a rule you must decide in advance.
• Counter-signing. Someone outside the decision chain is asked to review and record an opinion without holding the authority to approve or reject.
• Parallel approval. Several approvers receive the form at the same time because the order between them does not matter, so nobody waits unnecessarily in a chain.
• Overdue reminders. Something stuck too long should prompt automatically, rather than relying on the requester to chase.

Audit trail and versioning: being able to check afterward

This is the core advantage of an electronic system over group messages, and the part specifications most often miss.

A complete audit record needs at minimum: who, at what time, against which version of the content, took what action, and left what comment. The critical element is “which version.” If the content can be edited during the approval process and the system keeps only the latest copy, then the earlier approvals lose their meaning, because what those people agreed to was a different document.

The correct approach is to freeze the content once submitted, so that any change produces a new version and requires fresh agreement — or at the very least, the record marks which version each step approved.

Other points to watch:

• Records cannot be altered. A completed approval record should have no edit function, not even for administrators. Corrections are made through supplementary notes, never by changing the original.

• Retention periods. Different documents carry different statutory retention periods, so the system’s retention and deletion rules should be set from the regulations rather than left to a default. Common ones in Taiwan (current statutory text, checked September 2026):

  • Accounting vouchers are kept for at least five years, and accounting books and financial statements for at least ten, counted from the completion of the year-end closing (Article 38 of the Business Entity Accounting Act). On the tax side, Articles 26 and 27 of the tax authorities’ regulations on business account books and vouchers set the same ten years for books and five for vouchers.
  • Attendance records are kept for five years (Article 30, Paragraph 5 of the Labor Standards Act).
  • Payroll records are kept for five years (Article 23, Paragraph 2 of the Labor Standards Act).

  These are minimums; items that must be kept permanently or relate to unsettled accounting matters are excluded, and any industry-specific rules apply on top. Destroying the paper also follows a procedure: under Articles 26 and 27 of the tax authorities’ regulations on business account books and vouchers, only after that year’s corporate income tax return has been examined and assessed, and the competent tax office has approved it, may books or vouchers be stored electronically in sequence for the full retention period and the paper originals destroyed. Until assessment and approval, keep the paper. Ask your accountant how to file the application. Consider all this alongside the personal data principles discussed in How to Write a Website Privacy Policy.

• Exportable. An audit or review needs the complete process record exported, not a series of screenshots.

Relationship with HR, finance, and other systems

An approval system rarely should stand alone, but it also does not need to be connected to everything from the start. The test is: will the data be reused by somebody else once it is approved?

With HR systems. If approved leave, overtime, or travel has to affect leave balances, attendance statistics, or payroll, the data has to be exchanged, otherwise the same event is entered twice. The org chart and reporting relationships are usually authoritative in the HR system too, so the approval system should read them rather than maintain its own copy.

With finance or inventory. If an approved requisition becomes a purchase order, a payment request, or a journal entry, integration earns its keep. Think through the document flow alongside A Guide to Building Internal Admin Systems to decide which system owns the data.

With notification channels. Most companies want pending-approval alerts to arrive in the tool people already use. Pushing them through a LINE Official Account is the common approach in Taiwan. LINE is the dominant messaging app there, and an Official Account is its business-facing version; for how that works, see The LINE Bot Development Guide.

Sign-in integration. Do not make staff remember another set of credentials. Connecting to the company’s existing sign-in mechanism is convenient and means revoking access when someone leaves only has to be done once; see Social Login and SSO.

Integration does not have to arrive fully formed. Exchanging data through a scheduled export first and moving to a live interface later is a common and safe path. For the overall plan, see A Guide to System Integration and API Development.

Rollout rhythm: which forms to digitize first

Do not go live with everything. Choose the first batch on the basis of high usage, simple flow, and little controversy — leave requests and supply requisitions are the usual starting points.

A reasonable rhythm:

1. Pilot two or three forms, and use the opportunity to get the org chart, delegate rules, and notification plumbing right.
2. Run the pilot for a while and collect feedback, watching in particular for anyone bypassing the system. When people work around it, that usually means the design does not match reality, not that staff are being uncooperative.
3. Expand gradually to the more contentious forms, by which point there are internally accepted design conventions and discussion moves much faster.
4. Connect external systems last, once the forms and flows are stable.

Common mistakes and how to run acceptance

Pitfalls that recur:

• Copying the current process verbatim. A rollout is one of the few moments when reviewing a process is legitimate, and it is a waste not to cut the redundant steps. More approval steps does not equal better control; often it just disperses responsibility.
• Interviewing only managers. The people who actually fill in the forms know every exception, and exceptions are what systems miss.
• Ignoring role changes. When someone transfers or a department is restructured, does the route follow automatically? If this is not addressed up front, within months you will have forms stuck with people who have left.
• Neglecting the mobile experience. Approvers spend more time away from their desks than at them.

For acceptance, run complete real-world scenarios: a normal submission, a return for more information, an approval by a delegate, an overdue reminder, a withdrawal, and a cross-department addition. Run each once, then check whether the audit trail can fully reconstruct what happened. For how to organize acceptance, see How Software Acceptance Works.

When an approval system is done well, the most visible change is not that things move a few days faster. It is that nobody has to ask who approved something anymore. Once that holds, process analysis, bottleneck removal, and stronger internal controls finally have data to work from.

Do you already know which two or three forms you would digitize first? Bring those forms and the routes they currently travel, and talk to NETVANA about your project. We will map the flow and its exceptions with you before judging whether an off-the-shelf form tool, a low-code platform, or a custom build fits; software services are quoted on inquiry and never sold as fixed packages, and what each service includes and delivers is set out in the software services overview.

Further reading: to judge whether it is time to move from spreadsheets and manual routines to a system, see A Guide to Building Internal Admin Systems. If you do not know where to begin with a requirements document, follow the structure in How to Write Software Requirements. To push pending-approval alerts into a messaging app, see The LINE Bot Development Guide. To avoid another set of credentials, see Social Login and SSO. And because form data involves personal information, start with How to Write a Website Privacy Policy.