ERP Modernization · October 22, 2026 · 6 min read
Munis/EERP reports don't match: a finance team's reconciliation checklist
Work through differences between Munis/EERP reports by checking cutoffs, posting status, fund and account selections, and the transactions behind each total.
By Altioras Civic
Key takeaways
- Agree on the period, accounts, transaction status, and amount each report is meant to show.
- Compare detail by fund and account, then trace the transactions behind the difference.
- Assign the correction, rerun both reports, and have Finance review the reconciliation.
Start with the two reports that don't agree
If an accounts payable report doesn't agree with the general ledger, start by defining the comparison. An unpaid-invoice listing, a payment register, and an expenditure report answer different questions. Their totals may differ for valid reasons. Finance needs to establish which amounts should reconcile before anyone changes a report or posts an adjustment.
Tyler describes Enterprise ERP as powered by Munis. This guide uses Munis/EERP for that product context. Report names, available selections, and data access vary by release and deployment; confirm them in your agency's documentation. The checklist below is a recommended diagnostic sequence, rather than instructions for a particular screen.
Sources: Tyler Technologies — Enterprise ERP, powered by Munis
Agree what each total represents
Write a short definition beside each report: outstanding invoices at a cutoff, payments issued during a period, posted expenditures, or remaining budget. Identify the general ledger accounts or other records that should support the amount. Don't compare a balance at a date with activity over a date range and expect an automatic match.
For a budget comparison, confirm how the report treats original and amended appropriations, actuals, and encumbrances. Use the agency's approved definitions. A purchase order commitment and an invoice expenditure are different stages of the transaction; determine how each report presents them.
Record the sign convention too. A credit shown as a positive amount on one report and a negative amount on another needs a consistent treatment in the comparison.
Save the report settings and cutoff
Keep both original report outputs and the selections used to produce them. Record the fiscal year and period, date range, funds, departments, account ranges, transaction status, and run time. Include the report version or custom report identifier where available.
Check which date controls inclusion: invoice date, accounting period, posting date, or payment date. Review any year-end adjustment periods separately. If one output came from a reporting extract, record when that extract last refreshed. Transactions posted between two runs can explain a difference without either report being defective.
Agree on one comparison cutoff. During a busy close, retain the original outputs before rerunning anything so the team can distinguish a changed selection from newly posted activity.
Reconcile by fund and account
Compare the reports at the lowest common level available, starting with fund and general ledger account. Where useful, continue by department, project, or another shared identifier. Keep missing rows visible; don't let a spreadsheet lookup silently drop accounts that appear on only one side.
A net difference of zero can conceal offsetting differences between funds or accounts. Review the unmatched detail as well as the grand total. Check that opening balances, period activity, and closing balances are being compared consistently.
GFOA's discussion of faster financial statements recommends reconciling balance sheet accounts during the year, including comparing utility receivables and accounts payable records with the general ledger. Apply that principle to the specific accounts and reports Finance is reviewing.
Sources: GFOA — Issuing Financial Statements Faster, Government Finance Review, October 2021, p. 53
Trace the transactions behind the difference
Choose one fund and account that doesn't reconcile. Match transactions using the document, journal, batch, or other identifiers available in both outputs. Compare amounts and accounting periods. Preserve leading zeros and identifiers when exporting to a spreadsheet.
Look for transactions present on only one side, reversals counted in different periods, unposted batches, and records excluded by a report selection. For a transfer from another application, check the batch status and any rejected records before considering a retry.
Classify each difference as timing, selection, report calculation, posting, or source data. Record the transaction reference and explanation. Don't post an unexplained journal entry just to make the totals agree.
Check custom reports and access separately
If a standard report and a custom report disagree, ask the report developer to compare account mappings, date logic, exclusions, and joins to the underlying detail. A duplicated row in a reporting query needs a different correction from a duplicate transaction in the ledger.
If staff obtain different totals using the same selections, have the application administrator check their authorized data access. Do not broaden permissions to force a match. Also check whether they ran the same report revision against the same environment and refresh.
Use a reconciliation worksheet
Adapt this working table to the reports under review. Add the actual filenames, transaction references, difference, assigned person, due date, and reviewer to your internal copy. Keep resident, employee, vendor banking, and other restricted details in the agency's approved storage.
| Check | Compare or retain | Responsible role |
|---|---|---|
| Reporting scope | Fiscal period, cutoff, funds, accounts, and amount definition | Finance report owner |
| Posting status | Included batches, posted journals, and rejected transfers | Module owner |
| Fund and account detail | Both totals and unmatched account rows | Reconciliation preparer |
| Transaction differences | Document references, reversals, dates, and amounts | Finance and module owner |
| Report logic and access | Report revision, mappings, authorized scope, and refresh | Report developer or application administrator |
| Correction and review | Approved change, rerun reports, and remaining differences | Assigned person and Finance reviewer |
Assign the correction and rerun both reports
Route the issue to the person who can resolve it. Finance decides accounting treatment and approves journal entries. The application team reviews configuration. A report developer corrects report logic. An interface owner investigates failed transfers. Keep the agency's normal approval requirements in place.
After an approved correction, rerun the same comparison and check the affected transactions as well as the totals. For a report change, test another period or account range to check for unintended exclusions or duplication.
Update the internal close instructions when the resolution changes a recurring task. GFOA recommends documenting financial and accounting procedures, assigning responsibilities, and promptly updating procedures when they change.
Send support a case they can reproduce
If the difference remains, provide the product release, module, report names, selections, run times, expected amount, actual amount, and a small set of transaction references. State whether the issue occurs in a standard report, a custom report, or both, and when the comparison last agreed.
Use the approved support channel for restricted records. Give the case a business deadline, such as the scheduled close review, and assign an agency contact. Finance should retain the reconciliation and review the result before the issue is closed.