What should you monitor after ERP go-live?

ERP Implementation • Go-Live Support • Business Continuity

Our First 30 Days After ERP Go-Live: What We Monitor and Why

An ERP go-live is an important milestone, but it is not the finish line. The real test begins when employees start using the system for everyday work: sales orders are entered, goods are received, stock moves between warehouses, invoices are submitted and payments are recorded.

During the first 30 days, we need to look beyond whether the system is running. We need to know whether people are using it correctly, whether transactions are flowing as expected, whether errors are being resolved and whether operational and financial records reconcile.

1. Why the first 30 days matter

Consider an illustrative UAE distribution company, Gulfline Trading, which has recently moved its sales, purchasing, inventory and accounting operations to a new ERP system.

The system is live. Employees have their login credentials. Opening balances have been loaded, warehouses are configured and the implementation team has completed initial training.

But the first week reveals a different picture:

• Some sales employees continue to maintain a separate spreadsheet because they are unsure how to complete an order.
• A few purchase receipts are saved but not submitted.
• Warehouse employees are selecting the wrong destination warehouse during transfers.
• Finance users are unsure how to allocate customer payments against invoices.
• Support requests are increasing because employees are encountering real scenarios that were not covered in training.

None of these issues necessarily means the ERP has failed. They are signals that need to be investigated and managed before they become routine workarounds or reporting problems.

The purpose of the first 30 days: establish stable daily operations, identify recurring problems, build user confidence and confirm that important operational and financial records are accurate.

2. Monitor user adoption—not just logins

A user logging into the ERP does not automatically mean the user has adopted it. They may open the system, check a record and then continue doing the actual work in a spreadsheet or through email.

We need to understand whether employees are completing their responsibilities in the new system.

Check activity by role and department

Different teams use the ERP in different ways. Adoption should therefore be reviewed against each team’s actual responsibilities.

Look for signs of workarounds

During the first month, ask employees where they still use manual registers, personal spreadsheets, WhatsApp messages or email approvals to complete an ERP-related task.

Some temporary workarounds may be necessary during transition, but each should have an owner and a plan. Otherwise, the business ends up maintaining two versions of the same information.

Check whether users can complete key tasks

Instead of asking only whether training was completed, observe a few real tasks:

• Can a sales employee create and submit a sales order correctly?
• Can a warehouse employee receive goods against the right purchase order?
• Can a manager review and approve a document through the intended workflow?
• Can finance allocate a receipt to the correct customer invoice?

These checks reveal practical adoption gaps that login reports cannot show.

3. Watch transaction errors and incomplete processes

During the first few weeks, transaction problems often reveal gaps in configuration, data quality, training or process understanding.

We monitor more than error messages. A transaction can be technically successful and still be incorrect from a business perspective.

What should we check?

• Failed submissions: documents that cannot be submitted because of missing data, validation rules, permissions or configuration.
• Incomplete transactions: saved drafts, unsubmitted receipts, pending approvals and orders that have not moved to the next stage.
• Incorrect selections: wrong warehouse, customer, supplier, tax category, price list or account.
• Duplicate activity: repeated invoices, receipts, payments or stock entries created while users are trying to resolve an issue.
• Unexpected postings: transactions affecting the wrong account, stock quantity, party balance or reporting period.
• Integration failures: information that does not transfer correctly between connected systems, where integrations are part of the implementation.

Separate errors from expected behaviour

Not every document that does not appear in a report is an error. For example, a draft document may not create the same accounting impact as a submitted transaction. A sales order is a commercial commitment; it does not normally create General Ledger entries simply because it has been saved.

When investigating an issue, first confirm the document’s status and expected workflow. Then trace the source document and its related records before changing anything.

Track recurring error patterns

If several users encounter the same issue, it may indicate a process or configuration problem rather than an individual training gap.

For example, repeated errors involving warehouse selection may suggest that warehouse defaults, naming conventions or user instructions need attention. Repeated payment allocation issues may require a focused finance training session or a review of the payment process.

Do not only count errors. Record the type, frequency, business impact, root cause, owner and resolution. A declining error count is useful, but only when the underlying issues are actually fixed.

4. Treat support requests as operational feedback

The first month usually produces a mix of support requests. Some are simple questions. Others may reveal a configuration issue, a process gap or a technical fault.

Instead of treating every request as an isolated ticket, group them into categories.

Track support volume and resolution

Useful support measures include:

• Number of new requests received each day or week.
• Number of open requests and their age.
• Average time to first response and resolution.
• Requests grouped by department and issue category.
• Recurring issues and the number of users affected.
• Requests reopened after an attempted fix.

Prioritise by business impact

A question about changing a report layout should not receive the same priority as an issue preventing the warehouse from receiving goods or finance from posting customer payments.

A simple support priority model can help:

• Critical: major business operations are stopped, essential transactions cannot proceed or there is a serious data or security concern.
• High: an important process is affected and there is no practical workaround.
• Medium: a team or user is affected but can continue with an approved workaround.
• Low: guidance, minor usability or non-urgent reporting requests.

Every request should have an owner, an agreed response path and a clear status. Critical issues should be escalated through the agreed support arrangement rather than waiting for the next routine review.

5. Reconcile stock and financial records regularly

A system can look busy and still contain inaccurate information. This is why reconciliation is one of the most important activities during the first 30 days.

We need to confirm that the transactions recorded in the ERP reflect what actually happened in the business.

A. Inventory reconciliation

Compare the physical stock with the stock quantities recorded in the ERP. Review important items and warehouses, especially where goods are moving frequently.

Check:

• Physical quantities against book quantities.
• Goods received against purchase receipts.
• Deliveries against sales and delivery documents.
• Warehouse transfers against the actual movement of goods.
• Serial numbers, batch numbers and expiry details where applicable.
• Negative stock, unexpected adjustments and unusual valuation changes.

When a difference is found, investigate the source before posting an adjustment. A missing receipt, incorrect warehouse or duplicate stock entry may explain the variance. Adjusting the balance without understanding the cause can hide the real problem.

B. Accounts receivable and payable

Review outstanding customer and supplier balances. Confirm that opening invoices, new invoices, credit notes and payments are reflected correctly.

Pay particular attention to:

• Customer invoices that appear overdue but have already been paid.
• Payments that exist but have not been allocated to the right invoices.
• Supplier invoices with incorrect outstanding amounts.
• Duplicate invoices or credit notes.
• Opening balances that do not agree with the approved migration records.

C. Bank reconciliation

Compare the bank statement with the ERP’s bank ledger. Match receipts and payments, identify uncleared transactions and investigate bank fees or other missing entries.

A difference does not always mean an error. Timing differences can occur when a payment has been recorded in the ERP but has not yet cleared the bank. The team should identify and explain each outstanding difference.

D. General Ledger and Trial Balance

Review the General Ledger for unexpected postings and confirm that transactions are reaching the correct accounts. Compare the Trial Balance with the approved opening position and investigate unusual movements.

Check important areas such as:

• Sales and purchase accounts.
• Accounts receivable and payable control accounts.
• Bank and cash accounts.
• Inventory and cost of goods sold.
• Tax accounts and relevant liabilities.
• Suspense or temporary accounts used during migration.

Reconciliation is not just a month-end activity. During early go-live, frequent checks help identify errors while the transactions and people involved are still easy to trace.

6. Monitor system health and integrations

User adoption and transaction accuracy are only part of the picture. The technical environment also needs attention, especially where the ERP relies on background jobs, scheduled tasks, email services or external integrations.

Depending on the hosting model and system architecture, monitor:

• Application availability and response time.
• Database and storage capacity.
• Background jobs that fail, remain pending or take unusually long.
• Scheduled tasks that do not run as expected.
• Email delivery and notification failures.
• Integration queues, API errors and synchronisation delays.
• Backup completion and the ability to restore data.

For Frappe-based deployments, the System Health Report can help review areas such as background jobs, scheduler, database, cache, email, error logs, storage and backups. Frappe also provides logging and background-job monitoring tools for technical investigation.

See the Frappe Profiling and Monitoring documentation and Frappe Logging documentation.

Monitoring should match the deployment. A managed cloud environment and a self-hosted installation may expose different infrastructure metrics and support responsibilities.

7. Our first 30-day monitoring plan

The monitoring focus changes as the business becomes more comfortable with the new ERP. We use a phased approach rather than treating every day as the same exercise.

Days 1–7: Stabilise daily operations

The first week is about making sure people can perform essential work and that critical transactions are being recorded correctly.

• Confirm user access, roles and permissions.
• Observe key sales, purchase, warehouse and finance transactions.
• Review failed submissions and incomplete documents daily.
• Respond quickly to critical support requests.
• Check opening stock and important opening balances.
• Confirm essential integrations, notifications and background jobs are operating.

Primary question: Can the business complete its essential daily work in the new ERP?

Days 8–14: Build user confidence

Once the initial issues are under control, the focus shifts towards adoption and recurring errors.

• Review usage and process completion by department.
• Identify users who still depend on spreadsheets or manual registers.
• Group support requests by issue type.
• Run targeted refresher training for common problems.
• Review transaction errors and incomplete approval stages.
• Check stock movements and customer and supplier balances.

Primary question: Are employees becoming confident enough to use the ERP without repeated assistance?

Days 15–21: Resolve recurring problems

By the third week, the team should have enough operational evidence to distinguish isolated user mistakes from wider process or system issues.

• Investigate recurring transaction failures.
• Resolve repeated configuration and master-data issues.
• Review support ticket ageing and reopened requests.
• Check integration reliability and background job failures.
• Review stock differences and payment allocation issues.
• Confirm that approved process changes are understood by users.

Primary question: Are the same problems happening repeatedly, and have we addressed their root causes?

Days 22–30: Reconcile and review

The final phase focuses on confirming the reliability of business information and agreeing on the next stage of improvement.

• Complete agreed stock counts and investigate variances.
• Review bank reconciliation and outstanding items.
• Reconcile receivables, payables and opening balances.
• Review General Ledger and Trial Balance movements.
• Evaluate adoption, support trends and unresolved issues.
• Agree on the next improvement priorities with business owners.

Primary question: Can management rely on the ERP’s operational and financial information, and what still needs attention?

8. What should the go-live dashboard show?

A practical monitoring dashboard should help the project team see where attention is needed without overwhelming them with numbers.

We recommend starting with a small set of measures and expanding only when the information helps someone take action.

For every measure, define who reviews it, how often it is reviewed and what action is expected when it falls outside the agreed range.

The appropriate targets depend on transaction volumes, business hours, service arrangements and the criticality of each process. Avoid treating illustrative percentages or generic thresholds as universal go-live standards.

9. Who should be involved in the first-month review?

Go-live monitoring should not become the responsibility of the IT team alone. The people who own business processes need to review the results and approve corrective actions.

A short daily review may be useful during the first week, followed by scheduled reviews as operations stabilise. Critical incidents should always follow the agreed escalation process rather than waiting for a meeting.

10. How ERPNext supports post-go-live monitoring

ERPNext provides reports, transaction records and system tools that can help teams investigate operational and financial issues. The exact monitoring setup depends on the implementation, version, roles and any additional integrations.

General Ledger and Trial Balance

The General Ledger helps trace the accounting entries created by submitted transactions. The Trial Balance provides an account-level view of opening balances, movements and closing balances.

These reports are useful when checking whether invoices, payments, stock-related entries and other transactions are affecting the expected accounts.

See General Ledger and Accounting Entries.

Stock Ledger and Stock Reconciliation

The Stock Ledger Report provides transaction-level details of stock movements. Stock Reconciliation can be used to compare book quantities with physical counts and record approved corrections.

These are useful for investigating unexpected balances, warehouse discrepancies and stock valuation questions.

See Stock Ledger Report and Stock Reconciliation.

Bank Reconciliation and Payment Reconciliation

Bank Reconciliation helps match bank statement activity with accounting entries. Payment Reconciliation helps allocate submitted payments or credits against outstanding customer or supplier invoices.

These tools are especially relevant when finance teams are validating opening balances and the first month of live transactions.

See Bank Reconciliation and Payment Reconciliation.

System Health, logs and background jobs

For Frappe-based installations, system health checks and logs help technical teams investigate background jobs, scheduler activity, errors, database, cache, email and other operational components.

These checks complement business-level monitoring. A healthy application service does not automatically mean every business process is correct, so both views are needed.

See Frappe Profiling and Monitoring and Frappe Logging.

11. What should happen after the first 30 days?

The end of the first month should not mean that monitoring stops. It should mean that the business moves from intensive go-live support into a more sustainable operating rhythm.

At the 30-day review, we recommend agreeing on:

• Which critical issues have been resolved and which remain open.
• Which recurring problems need process, training or configuration changes.
• Which reports and reconciliation checks become part of the normal monthly close.
• Who owns ongoing support and escalation.
• Whether additional training is needed for specific roles.
• Which improvements should be prioritised for the next 60–90 days.

The team should also preserve the lessons learned. The issues that appear during go-live often reveal opportunities to improve the process, strengthen controls and make the ERP easier to use.

12. A successful go-live is measured by business confidence

For Gulfline Trading, the first 30 days are not judged by the number of transactions entered or the number of employees who logged in.

The more meaningful questions are:

• Can sales, purchasing, warehouse and finance teams complete their daily work?
• Are transactions being recorded accurately and at the right time?
• Are users asking fewer repeated questions because they understand the process?
• Are support requests being resolved and recurring causes addressed?
• Do stock quantities and financial balances agree with the supporting records?
• Can management trust the reports used to make business decisions?

When these areas improve together, the ERP becomes more than a system employees have been asked to use. It becomes a reliable part of the way the business operates.

That is what the first 30 days should help establish: stable processes, confident users, accurate transactions and information the business can trust.

Frequently asked questions

Make the first month count

At Craft Interactive, we believe ERP go-live should be followed by structured monitoring, practical user support and regular business checks. The goal is not simply to keep the system running—it is to help teams use it confidently and rely on the information it produces.

Planning an ERP implementation or preparing for go-live? Let’s discuss how to structure your transition and post-launch support.

Talk to Craft Interactive

Further reading

• Frappe: Profiling and Monitoring
• Frappe: Logging
• ERPNext: General Ledger
• ERPNext: Stock Ledger Report
• ERPNext: Stock Reconciliation
• ERPNext: Bank Reconciliation
• ERPNext: Payment Reconciliation