ERP rescue: is the problem a defect, configuration, data, or process?

Start with the task that failed

Finance says a posting is wrong. The implementation team says the setup matches the design. The support ticket says staff need training. At the next issue-review meeting, put the same transaction and approved requirement in front of all three teams.

GFOA describes an ERP system as software, processes, policies and people working together. Use that distinction when investigating a failure. The method below narrows one issue to a correction and a retest; it complements the broader recovery plan for scope, staffing and go-live.

For Tyler projects, Enterprise ERP is the product powered by Munis. Confirm your module, release, environment and configuration before applying these checks. This is a suggested investigation method, not a sequence of Munis screens or a claim about features included in every installation.

Sources: GFOA — Foundation for a Strong ERP System, December 2024; Tyler Technologies — Enterprise ERP, powered by Munis

Write down what should have happened

Have the department lead identify the requirement, approved procedure or accepted test case that defines the correct result. Record its reference beside the issue. If Finance and the implementation team disagree about the expected posting, the Finance owner must settle that rule before anyone declares a software defect.

Capture the transaction or batch reference, steps taken, user role, posting period, relevant selections, actual result and exact message. Record when it last worked, if known, and which records or departments are affected. Keep restricted records in approved storage and use the agreed support channel.

State the operational consequence separately: a blocked payroll run needs a different response from a report heading that can wait. A suspected cause does not determine priority.

Reproduce the problem under controlled conditions

Ask the ERP administrator to arrange an approved test environment and representative data. Confirm how it differs from production. A successful test on another release, a different role or an incomplete copy of the data may not explain the original failure.

Run the recorded steps, then compare the failing case with a known-good case that has the same relevant conditions. Change one suspected factor at a time and record each result. Do not replay payments, payroll postings or interface batches in production as a diagnostic shortcut.

Illustrative example: a test charge reaches the wrong fund. Compare its source coding, conversion mapping and posting setup with the approved account mapping. A bad source value points to data work; a correct source value routed by the wrong setup points to configuration. Both may need correction. The fact that the amount balances does not settle which fund should receive it.

Assign the next check before assigning blame

Use the table to decide who investigates next. These are working diagnoses; more than one cause may apply. A suspected product defect needs vendor investigation against documented, supported behavior. An unconfirmed label should not become a reason to stop checking.

Give each issue one named coordinator, even when Finance, IT and the vendor all have work to do. Record the next check, who performs it and when the team will review the result.

Keep staffing and policy decisions visible

Some issues remain open because nobody has time to investigate or authority to decide. Record that constraint separately from the technical diagnosis. Sacramento's February 24, 2026 PeopleSoft support report, for example, requested specialist capacity for enhancements, defects and configuration work. It was a support recommendation, not proof that every outstanding item was a software defect or that the work was completed.

When a correction changes a financial procedure, have the authorized agency owner approve it and update the staff instructions. GFOA recommends procedures that identify responsibilities and transaction authority. A consultant's proposed workaround does not change the municipality's approval rules.

Sources: City of Sacramento — File 2026-00470, February 24, 2026 council report; Description/Analysis; GFOA — Policies and Procedures Documentation

Use AI to prepare the meeting notes

An approved external AI tool could sort redacted issue notes into provisional groups and draft missing-information questions. Supply issue IDs, approved requirements and verified test notes; ask it to retain the source reference for each suggestion.

Have the test lead check every proposed group against the original record before assigning work. Reject invented causes and combined items that concern different transactions. Use approved calculations to reconcile amounts and control totals. This is a proposed use of a separately approved tool, not a claim about native Tyler functionality; AI should not change records, permissions or configuration.

Close the issue after staff repeat the task

Record the correction, change approval, test environment and release. Have the original tester repeat the failed scenario, then test nearby cases that could be affected. For a posting change, Finance should compare the transaction detail and ledger result with the approved expectation.

Keep the issue open if the task still fails. If an authorized workaround is necessary, record its limits, expiry or review date, responsible employee and remaining correction. The department owner accepts the result; the project sponsor decides any effect on go-live.

Bring the next meeting a short list: the failed task, the next check, the person doing it and the decision needed. Altioras Civic's ERP Implementation & Remediation service can help Finance, IT and the implementation team work through that list and retest the corrections.