xMatix
Sign in Request demo
xMatix
PRODUCTS
SalesField SalesCRMRewardsClaimsInventoryProcurementWarehouse ManagementField ServiceServiceSupportTelephony & MessagingFinance & AccountingPayrollExpense ManagementCommercePortalsAnalytics & ReportingData StudioMobile AppSee all products →
PLATFORM
Platform overviewApp BuilderAutomationIntegrationsSecurity & GovernanceChange ManagementDevelopers
SENSE AI
Sense AI overviewSense AssistSense ControlSense VisionAI StudioTrust & governanceIn Claude & ChatGPTUse cases
SOLUTIONS
FMCG & DistributionManufacturing & Dealer NetworksAutomotive & DealershipsPharma & HealthcareConsumer DurablesAgri-InputsBuilding MaterialsService NetworksWarehousing & 3PLFinancial AccountingERP SoftwareIndia GST ComplianceUAE VAT & e-InvoicingSaudi ZATCA & VATAll solutions →
RESOURCES
Knowledge CenterDeveloper & CLIBlogGuidesWhat is xMatix?Company facts
COMPANY
AboutCareersPartnersEventsContactAuthorsLegal
Sign in Request demo
Home/Docs/Expenses/Troubleshooting Expense Management
TROUBLESHOOTING · Last reviewed

Troubleshooting Expense Management

Expense problems sort into four families: a claim that will not go forward, a claim that approved but never posted, a posting or payment action that refuses with an error, and balances that do not tie. Find your symptom below — each entry names the cause and the fix, and the posting errors are decoded verbatim.

A claim will not submit

Check in this order:

  1. A hard-block result consumed by the submission flow. Policy evaluation records violations and returns a blocked flag, but it stops submission only where your business rule or approval entry actually consumes that result. Fix the flagged line—or the policy—and verify the integration rather than assuming the policy service alone gates the status change.
  2. The approval process did not pick it up. A record can hold only one pending request, the claim must match an active process's entry condition, and a process with zero steps is never selected. The generic checks are in Approval processes.
  3. The approver resolves to nobody. A manager step reads the manager field on the claimant's employee record — if that field is empty, there is no one to route to. Fill in the manager.

Approved, but never posted

The approval decision and the ledger posting are decoupled on purpose: a posting failure never rolls back the sign-off, it is logged instead. A claim showing approval Approved with posting NotPosted means the automatic post failed. Find the cause in the table below (the logs carry the same message), fix it, and run Post on the claim — posting is idempotent, so a claim that already posted is skipped, never doubled.

Posting errors, decoded

MessageCauseFix
"must be anchored on a Resource"the claim or advance has no claimant employee record setset the claimant and retry
"No Employee Payable control account … is configured"the control account is missing for this companycreate it in the chart of accounts with the Employee Payable control type
"No Employee Advance control account …"same, for advances — the account must also be a current assetcreate or recategorize the account as a current asset
"An ITC-eligible line needs a TaxCredit (Input GST) control account"a line claims input credit but no input-GST account existsconfigure the Tax Credit control account
"Expense claim has no postable expense lines"every line is missing an expense GL account or nets to zerogive each real line its expense account and amount
"Cannot post: expense category … is deactivated"a line still uses a retired categoryrecategorize the line
"Net reimbursable amount must be greater than zero"an advance adjustment already covers the whole claimsettle the claim via the advance instead of posting for reimbursement

Reimbursement refused

  • "Expense claim must be posted before it can be reimbursed." Post first — see the approved-but-never-posted section above.
  • "Expense claim is already fully reimbursed." The payable is settled; nothing is owed. If the employee disputes it, read the claim's journals — an earlier batch or an advance settlement cleared it.
  • "Claim is set to reimburse via payroll; finance reimbursement is not applicable." Use Settle via Payroll, or correct the claim's reimbursement mode if it was set wrongly.
  • "Batch has no payable claims to reimburse." Every batch line was skipped as unposted or already settled. The current batch handler leaves skipped lines Pending and stores no per-line skip reason, so reconcile the source claims directly and rebuild from Posted, unpaid claims.

The employee was paid the "wrong" amount

Almost always the right amount: the payment is the claim's open balance — the claimed total minus policy auto-disallowances (recorded per line with the rule that trimmed them) and minus advance settlements (recorded on the claim). Both deductions are visible on the record; walk them before suspecting the payment run.

Balances do not tie

If the employee-payable ageing disagrees with the control account's GL balance, something posted to the control account outside the subledger — typically a manual journal, or a reversal made in the GL without touching the open item. Run the employee-payable and employee-advance control-account reconciliations to locate the difference, and correct on the side that is wrong (reverse the stray journal, or fix the open item's document). The period-close checklist runs both checks as advisories, so an untied employee subledger is flagged before the period closes. Keep manual journals off control accounts as a standing rule.

Common questions

Who can unstick a claim locked in a pending approval?

The current step's approver (or their delegate or a reassignee) by deciding, the submitter by recalling it, or an approval administrator — who may act on any pending step. If the resolved approver has left, reassign the step or have an administrator decide.

A duplicate flag is wrong — how do I clear the claim?

Duplicate detection matches merchant, invoice number and amount against the claimant's other lines and prior claims. Blank invoice numbers on two different purchases are the usual false positive: fill in the real invoice numbers and re-evaluate. If the rule's action is warn, the claim can proceed regardless — the flag is information for the approver.

Posting failed days ago — did anything get lost?

No. The approval is intact, the claim is untouched, and no partial journal exists — the posting either completes whole or not at all. Fix the named cause and post; the claim picks up from exactly where it stopped.