ERP Work Needs an Operating Rhythm

The question is why an ERP meeting matters when the work appears to be a list of tickets, reconciliations, and configuration changes. The answer is that these items are not isolated. They are signals from the operating system of the business. When NetSuite operations, intercompany accounting, fixed assets, and reporting workflows are reviewed together, the team can see where the system is creating clarity and where it is creating drag.

What is at stake is not only close speed or clean reporting. It is the ability of finance and operations to trust the data they use to make decisions. A small mismatch in intercompany activity can become a recurring close issue. A manual fixed asset process can become a control gap. A reporting workflow that depends on spreadsheet interpretation can become a bottleneck when the business needs faster answers.

First principles help. The ERP should record activity once, classify it correctly, move it through the right approval path, and make it available for reporting without avoidable rework. Weekly operating discipline is how that principle becomes real. It creates a place to identify friction, assign ownership, and improve the system in small, durable steps.

The ERP meeting as a control system

A useful ERP meeting is not a status meeting in disguise. It is a control system. It compares current behavior against intended behavior, then decides what to change.

In the CMG NetSuite operations context, the meeting structure matters because the topics are connected:

• Operational transactions affect accounting outcomes.
• Accounting rules affect reporting reliability.
• Reporting gaps reveal process and configuration issues.
• AI integration depends on consistent source data.

If the meeting only reviews open items, it can become reactive. If it reviews patterns, dependencies, and root causes, it becomes a mechanism for better operations.

A simple operating rhythm can include:

• What changed in the system this week
• What broke or required manual intervention
• Which issues are recurring
• Which decisions are blocked
• Which controls need reinforcement
• Which automations are ready for testing

The goal is not to make every issue large. The goal is to distinguish between one-time exceptions and system design problems.

NetSuite operations: from tickets to patterns

NetSuite operations often begin with user requests: a role needs access, a saved search is returning unexpected results, a subsidiary needs a configuration adjustment, a vendor record needs cleanup. These requests matter, but the deeper work is pattern recognition.

For example, if users frequently ask for corrections to department or class coding, the issue may not be user training alone. It may point to unclear forms, weak defaults, missing approval checks, or inconsistent master data. If reporting teams repeatedly adjust the same saved searches after close, the issue may be that operational fields are not aligned with reporting requirements.

A weekly review should separate operational work into three categories:

Run

These are standard support tasks required to keep the system moving. Examples include access updates, minor configuration changes, user questions, and issue triage. Run work should be visible, but it should not dominate the meeting unless volume or severity changes.

Repair

These are fixes to known defects in process, configuration, or data. Examples include correcting incorrect subsidiary mappings, cleaning up duplicate records, or resolving posting errors. Repair work needs ownership and deadlines because it often affects close quality.

Improve

These are changes that reduce future manual work. Examples include automation, better dashboards, approval workflow changes, and reporting standardization. Improve work should be protected. Without it, the team spends every week repairing the same problems.

This structure keeps the meeting grounded. It also helps executives see whether the ERP is becoming more stable or simply being maintained through effort.

Intercompany accounting: remove ambiguity first

Intercompany accounting problems are often described as reconciliation problems. In practice, they are usually ambiguity problems.

The questions are basic:

• Which entity initiated the transaction?
• Which entity received the benefit?
• What is the correct due to or due from treatment?
• When should the transaction be recognized?
• Who owns the matching and elimination process?

If these questions are not answered consistently, the accounting team absorbs the ambiguity during close. That creates late adjustments, manual reconciliations, and difficult explanations.

A better approach is to define the intercompany operating model before optimizing the close process. The model should identify transaction types, source processes, required fields, posting rules, matching logic, and review responsibilities.

For NetSuite, this may include reviewing:

• Intercompany customer and vendor setup
• Subsidiary relationships
• Due to and due from accounts
• Intercompany journal templates
• Automated intercompany management settings
• Elimination subsidiary behavior
• Saved searches for unmatched balances

The weekly meeting should not attempt to solve every historical issue at once. It should isolate the highest-volume or highest-risk transaction flows and fix them in sequence. For example, management fees, shared service charges, reimbursements, and inventory-related activity may each need different treatment.

The practical standard is simple: if a transaction is expected to eliminate, the system should make that expectation visible before close, not after close.

Fixed assets: automation with accounting judgment

Fixed asset automation is attractive because the manual process is usually repetitive. Additions, disposals, depreciation, transfers, and reconciliations can consume time that should be spent reviewing judgmental items.

But automation should not begin with the software feature. It should begin with the asset lifecycle.

A clear fixed asset process answers:

• What qualifies as a capital asset?
• Who approves capitalization?
• Which fields are required at creation?
• How are asset classes mapped to accounts?
• When does depreciation begin?
• How are disposals approved and recorded?
• How are assets reconciled to the general ledger?

Once these rules are clear, NetSuite fixed asset functionality can be configured or improved with less risk. Automation can help create asset records from transactions, calculate depreciation, post journals, and maintain asset registers. But it should also preserve review points.

The strongest design is usually not full automation without oversight. It is controlled automation. The system handles repetitive calculations and postings, while finance reviews exceptions, thresholds, useful lives, and unusual transactions.

A good weekly meeting asks whether fixed asset work is reducing manual reconciliation or simply moving manual work to a different screen. If the asset register still requires significant offline correction, the process is not yet automated in a meaningful way.

AI reporting depends on source discipline

AI integration into reporting workflows can be useful, but only if the underlying data is stable enough to support it. AI can summarize, detect anomalies, draft commentary, explain variances, and help users query information in natural language. It cannot compensate for unclear definitions, inconsistent fields, or unreconciled balances without creating new risk.

This is why AI should be introduced as part of the reporting system, not as a separate experiment.

A practical reporting workflow might include:

• Standard NetSuite saved searches and datasets
• Defined reporting metrics and data owners
• Automated extracts or API connections
• AI-assisted variance explanations
• Human review of draft commentary
• Published reporting packages with version control

The value is not that AI writes the report. The value is that it reduces the time between data availability and management understanding. For example, if intercompany balances are clean and fixed asset depreciation is posted on schedule, AI can help identify drivers of variance across subsidiaries, departments, or account groups. If the source data is inconsistent, the same workflow will generate more questions than answers.

AI also changes the design requirement for reporting. Data definitions need to be more explicit. Account groupings, subsidiary structures, department mappings, and recurring adjustments should be documented. The model can assist with interpretation, but finance must define what correct interpretation means.

The weekly operating method

The meeting should produce decisions, not just awareness. A clear agenda can keep the work practical:

1. Review system health

Look at open issues, close blockers, integration failures, access concerns, and recurring user problems. The purpose is to identify risk early.

2. Review accounting impact

Connect system items to financial statement impact. Ask which issues affect revenue, expenses, intercompany balances, fixed assets, cash, or management reporting.

3. Review automation pipeline

Track fixed asset automation, reporting improvements, saved search changes, workflows, and AI reporting use cases. Separate ideas from items ready for design, testing, and deployment.

4. Confirm owners and dates

Every material issue needs one owner. Shared ownership often means no ownership. Dates should be realistic, but they should exist.

5. Capture decisions

Configuration choices, accounting treatments, and reporting definitions should be documented. The record of decisions becomes part of the operating system.

This method is intentionally plain. The sophistication comes from consistency.

What executives should look for

Executives do not need to inspect every configuration detail. They need to know whether the ERP environment is becoming more reliable.

Useful indicators include:

• Fewer recurring close adjustments
• Faster intercompany matching
• Lower manual effort in fixed asset reconciliation