Architecture & System DesignDOC-ARCHITECTURE-REAL-TIM

Real-Time vs Batch Processing in ERP

Understanding when real-time processing adds value versus when batch processing remains appropriate, including performance implications and architectural requirements.

11 min read
2,300 words
Updated 2026-02-24

The Processing Paradigm#

ERP systems must process transactions. The question is whether this processing happens in real-time (as each transaction occurs) or in batches (grouped transactions processed together). The right choice depends on the specific process and business requirements.

Batch Processing#

Batch processing has been the dominant paradigm in ERP systems for decades. Transactions are accumulated and processed together at scheduled intervals.

When Batch Processing Is Appropriate#

End-of-period processing: Month-end close, financial reporting, inventory valuation.

High-volume, low-urgency operations: Payroll processing, bulk order fulfilment, inventory updates.

Complex calculations: MRP runs, demand forecasting, allocation calculations.

Regulatory reporting: Tax filings, compliance reports that run on schedules.

Advantages#

Resource efficiency: Processing during off-peak hours optimises infrastructure utilisation.

Transaction integrity: All transactions in a batch can be committed or rolled back together.

Error handling: Failed batches can be corrected and re-run.

Predictable load: Processing windows are known and can be planned for.

Disadvantages#

Data latency: Information is stale until the next batch runs.

Peak load: Batch windows create concentrated processing demand.

Error propagation: Errors in batch processing can affect many transactions.

Real-Time Processing#

Real-time processing handles each transaction immediately as it occurs.

When Real-Time Processing Is Appropriate#

Customer-facing operations: Order capture, inventory availability, pricing.

Operational visibility: Production monitoring, warehouse operations, logistics tracking.

Time-critical decisions: Credit approval, fraud detection, stock allocation.

Customer experience: Omni-channel retail, self-service portals.

Advantages#

Current information: Decision-makers see current state, not stale data.

Immediate feedback: Errors are detected immediately, not discovered in batch reports.

Distributed load: Processing is spread across time, avoiding batch windows.

Disadvantages#

Higher complexity: Transaction management, error handling, and recovery are more complex.

Infrastructure requirements: Systems must handle peak real-time load.

Integration challenges: Downstream systems must also handle real-time data.

The Hybrid Reality#

Most organisations need both paradigms:

Real-time for customer operations: Orders, inventory, pricing.

Batch for financial operations: General ledger posting, reconciliations, reporting.

Real-time with batch reconciliation: Transactions processed in real-time but reconciled in batches.

Architectural Implications#

For Batch Processing#

Job scheduling: Robust scheduling tools for managing batch windows.

Batch monitoring: Visibility into batch status, duration, and errors.

Capacity planning: Ensuring sufficient resources for batch windows.

For Real-Time Processing#

Scalable infrastructure: Ability to handle peak loads.

Fault tolerance: Systems must handle failures gracefully without data loss.

Monitoring and alerting: Real-time visibility into system health.

NZ/AU Considerations#

Banking integration: NZ batch payment files vs emerging real-time payment APIs.

Time zone handling: Day-end processing across NZ/AU time zones.

Regulatory reporting: ATO and Inland Revenue filing schedules.

Conclusion: Match Processing to Requirements#

Real-time processing is not inherently better than batch processing. Each has appropriate use cases. Design your ERP architecture to use the right processing paradigm for each business process.