Test your Expense Management setup
Check your expense form, approval rules, approvers, and transfers before using real company funds.
Test your Expense Management setup
Run a complete test before using Expense Management with real company funds. The goal is to confirm that the request, approval, and transfer all follow the path you expect.
Use test employees, approvers, accounts, and amounts that are easy to identify. Tell the approvers before you begin so they know the requests are tests.
Start with a small amount and use accounts that your organization has approved for testing.
Prepare the test
Choose one example that represents a normal expense in your business.
| Test detail | Example |
|---|---|
| Requester | [email protected] |
| Category | Meals |
| Budget code | MKT-001 |
| Amount | PHP 100.00 |
| First approver | [email protected] |
| Final approver | [email protected] |
| Source account | Your approved expense source account |
| Destination account | Your approved test destination |
Write down the expected result before submitting the request. This makes it easier to notice a wrong rule, approver, or account.
1. Check the expense form
Open the expense request form and confirm that:
- The intended expense categories are available.
- The intended budget codes are available.
- Old or unused values are not shown.
- Required fields are clearly marked.
- The receipt and supporting document limits are clear.
Submit the test only after these values match your current policy.
Expected result: The requester can choose the correct category and budget code without seeing values that should no longer be used.
2. Check the approval rule
Compare the test request with your active workflow rules.
Confirm that:
- The request matches the rule you expect.
- The rule points to the correct approval template and version.
- More specific rules have lower priority numbers than the catch-all rule.
- The catch-all rule matches expenses that do not meet a specific rule.
- There is no second catch-all rule that could make the result unclear.
If you have a high-value rule, test an amount below the limit and another amount at or above the limit.
Expected result: Each test amount selects the intended workflow.
3. Submit the request
Submit the expense from the Dashboard or the Expense API.
Record:
- The expense ID.
- The submitted amount.
- The category and budget code.
- The approval ID, if you use the API.
- The time the request was submitted.
Open the request after submission and compare it with the original entry.
Expected result: The expense is pending, the details are unchanged, and the first intended approver can see the request.
If the expense is approved immediately and a transfer starts, check expense_approvals_enabled. A false or missing value skips the approval workflow.
4. Test each approval stage
Ask the first approver to approve the request. Confirm that it moves to the next stage and is no longer waiting for the first approver.
Repeat this for every stage.
For each stage, check:
- The right people can see the request.
- People who are not assignees cannot approve it.
- The stage follows its configured mode.
- The activity history records the decision.
- The request moves to the next stage only when the stage is complete.
For an any_of stage, one assignee should be enough. For an all_of stage, every assignee must approve.
Expected result: The request follows the stages in order and reaches the approved status only after all required decisions are complete.
5. Check the transfer
After final approval, confirm that the transfer uses the expected details:
- Source account.
- Destination account and account name.
- Destination bank identifier.
- Amount and currency.
- Expense ID or other reference used by your team.
Check the available balance on the source account and the transfer status.
Expected result: One transfer is created for the correct amount, from the correct source account, to the correct destination.
6. Test a rejection
Submit a second small request and ask an approver to reject it.
Confirm that:
- The request status changes to rejected.
- Later approval stages do not start.
- No transfer is created.
- The activity history shows who rejected the request.
- The requester can see the final result.
Expected result: A rejected expense stops before any transfer is created.
7. Test important rule boundaries
Test the values where your rules change. For example, if expenses worth PHP 5,000 or more need Finance approval, test:
| Amount | Expected workflow |
|---|---|
| PHP 4,999.99 | Standard approval |
| PHP 5,000.00 | High-value approval |
| PHP 5,000.01 | High-value approval |
API amounts use centavos. PHP 5,000.00 is 500000 in an API request.
Also test any rules based on category, budget code, or employee email.
Expected result: Values at each boundary choose the correct workflow.
Keep a test record
For each test, record the expense ID, workflow used, approvers, final status, transfer ID, and any unexpected result. Keep screenshots or response bodies if your team needs evidence for review.
Fix any mismatch, then repeat the full test. Do not rely only on the step that failed because a change to one rule can affect another path.
Ready for production checklist
Expense Management is ready when:
- Categories and budget codes match your current policy.
- The transfer source account is correct.
- Every approval stage has the intended assignees.
- At least one active rule matches every valid expense.
- Specific rules run before the catch-all rule.
- A normal request reaches the expected approvers.
- Rule boundary tests choose the expected workflows.
- An approved request creates one correct transfer.
- A rejected request creates no transfer.
- Request, approval, and transfer records can be traced by your team.
Repeat these checks after changing categories, budget codes, source accounts, templates, assignees, or rules.
Updated 6 days ago
