How should the expense control system be accepted after going live? Kailing Technology Lingdong Reimbursement uses normal orders and exception orders to test the complete business closed loop

At nine in the morning on the launch acceptance day, no feature demonstration was shown first in the meeting room. The business representative handed two travel invoices to the test team: the first was for normal business travel, with complete invoices, itinerary, and expense items; the second mixed in an invoice that had already been reimbursed, had buyer header information inconsistent with the enterprise information, and pushed the accommodation amount beyond the budget line. Employees, approvers, finance, cashiers, accountants, and IT staff gathered around the test table to see at which node the two documents would diverge.

The acceptance goal of Kailing Technology's Lingdong Reimbursement is also clarified by this: normal forms go all the way from invoice collection to archiving, with fields and statuses continuously written back; exception forms stop when a rule is hit, give a processable reason, and are resubmitted along the original form after the employee supplements the materials. Acceptance personnel record the on-site phenomenon, system response, role action, and final evidence at each step, and verify the complete business closed loop by running the two types of forms in parallel.

▍Before acceptance begins, write the two documents into executable test scripts

The project manager first writes clearly for the normal order the employee, organization, expense type, budget project, approval route, receiving account, and voucher template; then presets three conflicts for the exception order: the same invoice already exists in the invoice pool, the buyer title is inconsistent with enterprise information, and the accommodation amount triggers a budget rule. Each conflict notes the expected stopping node and handling position.

The script arranges invoice collection, duplicate checking and authenticity verification, automatic order creation, rule approval, payment, voucher conversion, and archiving in actual order. Testers do not skip steps or manually change status from the backend. At each node passed, the entry time, operator, input fields, system prompts, and output status are recorded.

Pass criteria are written into the script in advance: normal order fields are collected once and continuously reused, exception orders are intercepted at set positions, return reasons can be understood by employees, corrections continue from the original business, and payment, vouchers, and archives can all be traced back to the original invoice. Everyone on site observes around the same set of criteria.

▍Normal travel orders enter the invoice pool from invoice collection and complete duplicate checking and authenticity verification

Employees use their phones to collect normal invoices, and the system recognizes the invoice type, number, date, seller, and price-tax information, while saving the electronic invoice source file. After the invoice enters the personal invoice folder, the employee selects it to initiate travel reimbursement, and the organization, header, and expense content are brought in with the invoice.

Finance observes three results in the invoice pool: whether invoice face fields are fully recognized, whether the tax number and enterprise name pass verification, and whether the same invoice has only one valid occupation relationship. After a normal order shows as available, the system automatically generates a reimbursement form, and the employee only supplements the business trip reason, project, and attachments.

Acceptance personnel then return from the reimbursement form to the invoice pool and check the two-way association between form and invoice; then use another account to repeatedly upload the same invoice, and the system should prompt duplication and prevent adding it again. This action simultaneously verifies the normal path and the duplicate risk entry.

Invoice pool exceptions and duplicate-check status (information desensitized)

▍Exception orders stop layer by layer at duplicate invoices, header errors, and budget overruns

The test team first submits an exception form with a duplicate invoice. The system marks the occupied record during invoice validation and displays the linked document, so employees do not need to wait until finance final review to know the reason. Testers capture the prompt, linked number, and current status, confirming that the exception did not enter the next approval node.

After replacing with a new invoice, the employee retains the wrong buyer title. Invoice validation points out that the enterprise name or tax number is inconsistent with the current organization data, and the employee continues to submit only after switching back to the correct invoice. When entering rule review, the accommodation amount triggers a budget condition, and the digital employee displays the hit policy item and pushes the task to the designated approver.

The on-site observation point is not whether the prompt color is eye-catching, but whether the exception can be located to a specific invoice, field, and rule, who receives the to-do, whether the original attachment is retained, and whether the status stops at the correct node. The three conflicts are identified in sequence, and the expected results in the test script are checked off item by item.

Digital employee prompts a rule exception (information desensitized)

▍Return and resubmission verify the continuity of original order correction and approval records

The approver opens the exception form, sees the budget match, invoice attachments, and employee explanation, chooses to return it to the initiator, and fills in the travel basis that needs to be supplemented. The employee enters from the original to-do, the system retains the filled content and historical comments, the page locates the fields that need modification, and the employee completes the correction along the original form.

The employee supplements attachments and adjusts expense attribution, then submits again. Acceptance personnel check whether the invoice occupation continues, whether the document number remains the same, whether old approval comments are arranged by time, and whether the new process continues from the configured node. After the approver passes it again, the exception order moves to pending payment status.

Then, from the approval log, reverse-view initiation, rule hits, manual returns, employee corrections, and passing again. Each action has personnel, time, and result, and the business representative can reconstruct why this order was returned, what was changed, and who released it.

▍Two approved orders enter payment and then observe bank results and anti-duplication actions

The cashier separately selects the normal order and the corrected exception order to generate payment tasks, and the system brings out the employee account, reimbursement amount, and document relationship. The test team first makes the normal order obtain a success receipt, then simulates incorrect account information for the exception order, and observes whether the two tasks are updated independently.

After the normal form receives the bank receipt, the reimbursement status switches to paid, and the receipt is automatically linked to the original form. The exception form displays the return reason and enters the pending list; after the cashier corrects the account, a new instruction is initiated from the original task, and the first failed transaction remains on the payment timeline.

Testers repeatedly click submit and simulate an interface timeout; the system first queries the original instruction result to avoid generating a second valid payment. Passing criteria include item-by-item write-back of bank status, separately repairable failed items, employees being able to see payment progress, and finance being able to return from the receipt to approval and invoices.

Payment results linked to bank receipts (information desensitized)

▍After payment is completed, continue through to voucher generation rather than stopping at successful disbursement

The accountant opens a paid document, and the voucher conversion middleware brings out the account, amount, organization, project, and auxiliary accounting according to the mapping rules. After a normal order generates an accounting voucher, the voucher number is written back, and an exception order also generates corresponding data along the corrected expense attribution.

The acceptance team temporarily removes an auxiliary accounting value and observes that the system keeps the order in the pending queue and points out the missing item; after restoring the field, it converts again from the original reimbursement form. Accounting verifies that the new result did not duplicate the reimbursement form and did not generate two valid vouchers.

Pass criteria land on field consistency and continuous association: reimbursement amount matches voucher amount, expense items enter the correct accounts, organizations and projects can be received downstream, and voucher numbers return to Lingdong Reimbursement. Accounting views the original invoice, approval, and bank receipt from the voucher, and the chain remains complete.

Reimbursement form to voucher and failure handling (information desensitized)

▍The archiving stage checks whether source files, approvals, receipts, and vouchers form a complete set

The archive role views the two reimbursement forms at the electronic accounting archives entry. A normal form should include the invoice source file, reimbursement form, attachments, approval records, bank receipt, and accounting voucher; an exception form should also retain the rule hit, return comments, revised version, and failed payment transaction.

The test team then imports a red-letter invoice linked to the original blue invoice, checks whether the invoice pool can indicate the original invoice relationship, and hands the affected reimbursement, voucher, and archive to finance for review. After processing, the invoice, document, and voucher are traced back from the archive, and both new and old records remain in the original business relationship.

After both documents are fully closed, the test team exports the case records and screenshots. What the business representative sees is the employee experience from invoice collection to payment inquiry, what finance sees is rules, payments, and vouchers, and what the accounting archive position sees is a traceable set of materials.

Electronic accounting archives association check (information has been desensitized)

▍Acceptance handover results in defect closure and delivery of regression scripts

At the acceptance meeting, the test script is checked item by item. All seven segments of the normal order pass, and the exception order's duplicate invoice, title error, and budget overrun all trigger at predetermined nodes, leaving records for payment returns, interface timeouts, red-reversal invoice review, and archive reverse lookup. Interface prompt or interface issues found enter the defect list.

Each defect states the reproduction steps, affected role, expected result, owner, and retest evidence. After repair, rerun the affected segment, then use a normal form to regress the main chain. Kailing Technology and the enterprise project team jointly confirm the status of key use cases, and operations staff simultaneously receive the log location, exception queue, and handling manual.

After handover is completed, these two desensitized test orders are retained as subsequent regression samples. When approval rules, bank interfaces, or voucher mappings change, the team reruns the same script and compares each observation point. One acceptance thus becomes a continuously upgraded business testing asset.

▍FAQ

Q: Why is it necessary to prepare normal orders and exception orders for expense control system acceptance?

A: Normal orders verify the continuity of the main chain, while exception orders verify interception, return, correction, and recovery. Only the two types of samples together can cover real operations.

Q: Does a duplicate invoice prompt mean the exception test has passed?

A: It is also necessary to check whether the related documents, current occupation, handling position, and subsequent release or replacement actions are clear.

Q: Can acceptance end after payment succeeds?

A: The acceptance script continues to check receipt linkage, voucher conversion, and electronic archives until the entire business can be traced back from the archives.

Q: How can retesting be done quickly after a process adjustment?

A: Keep the desensitized normal orders, exception orders, expected results, and observation points, and run the regression script according to the affected stages.

Use normal orders and exception orders together to verify the expense control closed loop, and learn about Kailing Technology Lingdong Reimbursement acceptance method: https://www.kailingteck.com/feikong/ .

As a national high-tech enterprise, Kailing Technology focuses on the digital and intelligent transformation of enterprise business-finance-tax and operations management, providing software products, system integration, implementation and delivery, and operational services for various government agencies, institutions, group enterprises, and SMEs.

The company has now formed ten core product lines, including: AI digital employee system, enterprise expense control management system, customer relationship management system, reverse invoicing management system, invoice issuance for individuals management system, electronic archives management system, tax fully digitalized e-invoice Leqi system, tax invoice management system, group tax filing system, and AI OCR recognition system. It is committed to connecting enterprise business, finance, tax, funds, and archive data to help customers improve operational efficiency, business-finance-tax compliance capabilities, and digital management levels.

If you have any business-finance-tax digital transformation needs, welcome to contact us. Beijing Kailing Technology will serve you wholeheartedly.

Keywords: expense control system acceptance, Lingdong Reimbursement, reimbursement exception testing, bank-enterprise direct connection acceptance, voucher archiving testing