How the OA reimbursement module differs from an expense control system? Comparison of 6 scenarios
For simple reimbursement approval, OA is fully sufficient; there is no need to switch. The gap appears in three types of scenarios: one expense must be allocated across multiple projects, loans must be reconciled with reimbursements, and the same expense type enters different accounts by department. What these three have in common is that they are not process issues but accounting logic issues, and OA form engines are not designed for accounting logic.
First explain what OA is good at
What OA is best at is Documents plus approval: Apply for vehicles, approve contracts, apply for marketing budgets, initiate recruitment. How many approval levels in between, whether to escalate for large amounts, how to remind about pending tasks, who can see which documents—OA has done this for many years, mature and reliable.
On the surface, reimbursement is also just a form plus an approval flow. So using OA for reimbursement works perfectly when the business is simple, and it saves the procurement and maintenance cost of another system.
Actual Comparison of Six Scenarios
| Scenarios | OA reimbursement module | Professional expense control system |
|---|---|---|
| Submission, multi-level approval, to-do reminders | Fully capable | Equivalent |
| Invoice Verification and Duplicate Reimbursement Identification | Most require plug-ins or manual work | Built-in, verification and duplicate checking upon document submission |
| One expense allocated to multiple projects | Forms can be filled in, but vouchers after allocation must be handled manually. | Allocation lines independently generate entries, each carrying project dimensions |
| Loan and Reimbursement Offset Reconciliation | Usually not achievable, relying on Excel ledgers | The loan balance is automatically populated when submitting a request, and return/settlement/overspending is automatically determined by amount |
| The same expense type enters different accounts by department | Judgments need to be hard-coded in the process; once a rule changes, the process must be changed | Multi-condition rule matching, with priority automatically determined by the number of conditions |
| Cross-period, closing, red-letter reversal | Basically not covered | Configurable bookkeeping date basis, pre-check of accounting periods, and red-letter reversal for voiding |
The first two rows show no obvious disadvantage for OA. What truly creates the gap is the last four rows, and these four rows happen to be where finance spends the most time every month.
Why doing these things on the OA platform is so laborious
First, it is limited by the platform's data structure. OA forms are designed for processes, where one form corresponds to one main record plus several details. Allocation, however, requires 'one detail split into multiple lines, each line carrying different dimensions,' and vouchers require 'multiple lines on both debit and credit sides with self-consistent amounts,' which are very awkward to express in a form engine.
Second, a rule change equals a process change. In OA, account determination logic is often written in process nodes or form formulas. If finance wants to adjust an account mapping relationship, it has to modify the process, test, and republish. In a rules engine, this is just changing one piece of configuration data.
Third, customization costs are high. OA vendors usually quote implementation by person-day, and such deep customization is not within the scope of standard products. After completion, when upgrading the OA version, the customized parts may also require regression testing.
A compromise solution
No need to choose one over the other. A more practical approach is Approval entry stays in OA, deep business stays in the expense control system: Employees still submit and approve documents in OA, Feishu or DingTalk as before; after approval, the documents are synchronized to the expense control system, which completes verification, allocation, write-off, voucher generation and payment, and then writes the status back to OA.
In this way, employees do not need to change their usage habits, the existing OA investment is not wasted, and finance-side capabilities are no longer limited by the form engine.
How can you determine whether you need to switch
Three questions, and it's clear once you answer them:
I. Does the reimbursement form need to carry a project or cost center and be allocated by it? II. Does the company have employee loans, and do they need to be reconciled with reimbursements? III. For the same expense type, do different departments enter different accounts?
If all three are "No", the OA is sufficient, don't bother. If one is "Yes", it's worth doing the math: How much time finance spends manually handling this each month, the annual labor cost, and how that compares with the investment in a system.
How is this scenario handled in Kailing Technology's expense control system?
Kailing Technology's expense control and reimbursement system can integrate with OA systems such as Seeyon and Weaver, as well as Feishu, DingTalk, and WeCom. The approval entry point remains on the original platform, while expense allocation, loan write-off, voucher generation, and payment are completed on the expense control side with status written back. Rules are maintained through configuration, and adjustments to account mapping relationships require no process changes or re-releases.
Learn about the Kailing Technology expense control and reimbursement system →
Common Questions
Look at three questions: whether allocation by project is needed, whether employee loans need to be reconciled, and whether the same expense type enters different accounts by department. If all are no, there is no need to switch.
OA solves process problems, while expense control solves accounting logic problems. Allocation, reconciliation, and multi-condition account matching cannot be expressed by processes.
Yes, this is the recommended compromise solution. The approval entry remains in OA, deep business functions are placed in expense control, and status is written back to OA.
Technically feasible but costly: limited by form data structures, rule changes amount to process changes, customization fees are charged per person-day, and regression testing is required during upgrades.