What Is Ecommerce ERP and How Does It Work? A Simple Guide for Online Sellers

Some links on The Justifiable are affiliate links, meaning we may earn a small commission at no extra cost to you. Read full disclaimer.

If you are asking what is ecommerce ERP and how does it work, you are dealing with a familiar growth problem: your store sells through more channels, inventory moves faster, and spreadsheets or disconnected apps no longer give you a reliable picture of the business.

Ecommerce ERP software brings core operational data into one coordinated system so orders, stock, purchasing, finance, and fulfillment can work from the same records.

This guide explains what ERP does, when it becomes useful, how integration works, what to prepare before implementation, and how to choose a setup that supports growth without creating unnecessary complexity.

What Ecommerce ERP Means in Everyday Operations

An ecommerce ERP is easier to understand when you separate the customer-facing store from the operational systems behind it. The storefront takes the order; the ERP helps the business coordinate what must happen next.

How an ERP Differs From Your Ecommerce Platform

Your ecommerce platform is primarily built to help customers browse products, add items to a cart, pay, and receive updates about their purchase. A platform such as Shopify or WooCommerce can also handle useful operational tasks, but the storefront is not automatically the master system for every process in a growing business.

An ERP, or enterprise resource planning system, connects operational functions that would otherwise live in separate tools. Depending on the product and configuration, that can include inventory, purchasing, supplier records, accounting, order management, warehouse activity, product data, returns, and reporting.

Think of the relationship this way: the ecommerce platform records that a customer bought three units. The ERP determines what that sale means across the business. Inventory falls, revenue and tax records may need updating, a fulfillment task may be created, replenishment demand may change, and managers may want the sale reflected in reporting.

This distinction matters because many sellers try to make one application perform every job. A better approach is to decide which system owns each type of data and then connect those systems deliberately.

What Data an Ecommerce ERP Usually Manages

The practical value of ERP comes from shared records. Instead of one stock number in the store, another in a warehouse spreadsheet, and a third in accounting, the business defines which system is authoritative and how updates move between applications.

Common ERP data domains include products and variants, inventory by location, purchase orders, supplier information, sales orders, customer records, invoices, taxes, payments, returns, costs, and financial transactions. More advanced implementations may also cover manufacturing, demand planning, landed costs, B2B pricing, multiple legal entities, or international operations.

Not every seller needs every module. A direct-to-consumer brand with one warehouse may care most about inventory, purchasing, orders, and accounting. A wholesaler selling online may need customer-specific price lists, credit terms, and approval workflows. A company assembling products from components may need bills of materials and production planning.

The important decision is not “How many ERP features can we buy?” It is “Which business records must stay accurate as volume and complexity increase?” Start with those records. Adding modules simply because they exist can make implementation slower and harder to maintain.

How Ecommerce ERP Integration Actually Works

ERP integration is the connection that allows your commerce platform and ERP to exchange data. Some connections are direct. Others use a connector, integration platform, middleware, or custom application programming interface, usually called an API. The technology matters, but the data rules matter more.

A typical flow starts when a customer places an order. The commerce system sends order details to the ERP. The ERP creates or updates the sales order, adjusts available inventory according to the configured rules, and may pass fulfillment instructions to a warehouse. Shipment information can then move back to the storefront so the customer sees the correct order status.

Some information should move almost immediately. Inventory availability is a good example because a long delay can cause overselling. Other information may be synchronized in scheduled batches. Financial reconciliation or certain reporting records may not require second-by-second updates.

A reliable integration also defines direction. Product cost might come from the ERP, while the storefront might own merchandising copy. If both systems can overwrite the same field without clear rules, conflicts become inevitable. Integration is therefore a combination of software connection, data ownership, timing, and exception handling.

Why Online Sellers Adopt ERP Instead of Adding More Apps

ERP usually becomes attractive after operational complexity begins creating errors, delays, or limited visibility. The goal is not simply to replace apps; it is to reduce the number of disconnected processes people must manually keep in agreement.

The Operational Warning Signs That Matter

Order volume alone does not determine whether you need ERP. A store with 10,000 simple monthly orders may run efficiently with a focused stack, while a lower-volume business with multiple warehouses, wholesale customers, kits, suppliers, and international entities may face much greater operational complexity.

Look for recurring friction. Your team may be exporting orders to spreadsheets, reconciling stock between channels, entering the same supplier invoice twice, or discovering inventory errors only after customers purchase unavailable products. Month-end reporting may depend on manual cleanup. Purchasing decisions may rely on instinct because sales, stock, incoming supply, and lead times live in different places.

Another strong signal is organizational dependence on one or two people who “know how everything connects.” If operations stop when those people are unavailable, the business has undocumented process risk.

I recommend tracking these problems for several weeks instead of buying software after one painful day. Note how often each issue happens, how much staff time it consumes, and what it costs in cancellations, delays, expedited shipping, or accounting corrections. Those numbers create a much better ERP business case than vague frustration.

What ERP Can Improve When It Is Implemented Well

The main benefit of ERP is coordinated information. When systems share reliable records, teams can make decisions without repeatedly rebuilding the same picture of the business. Customer service can see order status. Purchasing can compare sales demand with stock and incoming purchase orders. Finance can work with cleaner transaction data. Operations can identify exceptions earlier.

Automation is another benefit, but it should come after process clarity. For example, an accepted sales order can trigger inventory allocation, fulfillment instructions, and accounting entries based on predefined rules. That removes repetitive work and reduces the opportunity for manual entry mistakes.

ERP can also improve control as a company grows. Permissions, approval rules, standardized workflows, and consistent reporting make it easier to operate across departments or locations without inventing a new process every time volume increases.

However, ERP does not automatically improve a broken workflow. If product codes are inconsistent, warehouse procedures are unclear, or staff use unofficial spreadsheets, the new system can reproduce those problems at larger scale. The value comes from combining software with disciplined process design, data governance, and user adoption.

I suggest treating ERP as an operating model project, not an IT purchase. The software matters, but the biggest gains come from deciding how work and data should flow.

When ERP Is Probably Too Much for Your Store

A small seller does not need enterprise resource planning simply because the term sounds more professional than “inventory software.” If you have one store, a manageable product catalog, one fulfillment location, uncomplicated accounting, and a small team, a combination of ecommerce, accounting, and inventory tools may be easier and cheaper to operate.

For example, a seller using a storefront plus Xero for accounting may already have enough structure if orders and inventory reconcile reliably. Adding ERP could create implementation work, subscription cost, training requirements, and administration without removing a meaningful bottleneck.

A useful test is to ask whether your current problem is local or systemic. If warehouse picking is slow, better warehouse procedures may solve it. If inventory is accurate except for one marketplace connector, fix the connector. ERP is more appropriate when several functions depend on the same inconsistent data and isolated fixes keep creating new gaps.

Also consider management capacity. ERP requires someone to own processes, permissions, integrations, and change control. If nobody can take responsibility for those decisions, delaying the project while improving documentation and data quality may produce a better outcome than rushing into implementation.

Prepare Your Business Before Comparing ERP Products

The fastest way to make ERP selection confusing is to start with product demos. First document how your business works today, what must improve, and which data should control each operational decision.

Map the Order-to-Cash and Purchase-to-Stock Workflows

Begin with two end-to-end workflows. Order-to-cash covers what happens from customer purchase through payment, fulfillment, returns, and financial recording. Purchase-to-stock covers demand identification, purchase orders, supplier receipt, inventory availability, invoices, and payment.

Write each workflow as it actually happens, not as your policy manual says it should happen. Include spreadsheets, manual messages, copied data, and exceptions. If customer service asks the warehouse in chat whether an item shipped, record that. If finance downloads marketplace reports every Friday and manually matches fees, record that too.

Then mark each handoff where information changes systems or owners. Those handoffs are common failure points. Ask what data enters, which system creates it, who verifies it, and what happens when something is missing.

A simple mapping exercise often reveals that the ERP requirement is not “better reporting” but something more concrete, such as unified SKU-level inventory, automated purchase-order receiving, or a dependable connection between returns and accounting.

Do this before vendor evaluation because clear workflows let you test software against real scenarios. Otherwise, polished demonstrations can make nearly every platform appear suitable.

Clean the Data You Expect the ERP to Use

ERP software depends on structured data, and migration exposes years of small inconsistencies. Duplicate customers, mismatched SKU formats, inactive products, outdated supplier records, negative inventory, inconsistent units of measure, and incomplete tax settings can all create problems when imported.

Start by identifying master data: the records that other transactions depend on. Products, variants, suppliers, customers, warehouses, account codes, tax rules, and units of measure are common examples. Decide which records are active and which should be archived rather than migrated.

Next, define naming and coding rules. If the same product is SKU “BLUE-M” in one system and “BL-MED” in another, choose the canonical identifier before integration. Do the same for locations and supplier codes.

Avoid using migration as an excuse to move every historical record. Some businesses need detailed transaction history in the ERP; others can preserve legacy data in a read-only archive while migrating opening balances and active records. Your accounting, tax, support, and reporting requirements should determine the approach.

Clean data reduces testing time because you are validating workflows rather than debugging preventable inconsistencies.

Define System Ownership Before You Integrate Anything

For each important data field, decide which system is the source of truth. This is one of the most important ERP design decisions because two-way synchronization can become destructive when both systems are allowed to “win.”

Consider inventory. The ERP may own on-hand stock by warehouse, while the storefront receives an available-to-sell quantity after safety stock and reservations are applied. Product titles and descriptions might be managed in the commerce platform, while SKU, cost, tax class, and purchasing information remain ERP-owned.

Write these rules in a data ownership matrix with three simple columns: data object, master system, and receiving systems. Add synchronization frequency and exception handling if needed.

Be especially careful with customers, prices, refunds, and orders because these records may change in multiple systems. For example, a customer service agent might edit an address after the order has already entered fulfillment. Your workflow must define whether that change can update the ERP and whether the warehouse should receive it.

Clear ownership prevents sync loops, mysterious overwrites, and endless arguments about which screen is correct.

Choose an Ecommerce ERP Based on Process Fit

ERP selection should move from business requirements to software, not the reverse. The right platform is the one that handles your critical workflows with reasonable configuration, reliable integrations, and a manageable total cost of ownership.

Separate Must-Have Requirements From Attractive Features

Create a requirements list and classify each item as must-have, important, or optional. A must-have is something the business cannot operate correctly without, such as multi-location inventory, serialized products, B2B price lists, manufacturing, or country-specific financial requirements.

Write requirements as scenarios rather than feature names. “Supports inventory” is too vague. “Reserve inventory across two warehouses, prevent overselling online, and show customer service the allocation status” is testable. “Handles returns” is weaker than “receive a partial return, restore sellable stock, write off damaged stock, and send the correct financial adjustment.”

This approach also helps you avoid paying for complexity you do not need. A system may offer advanced manufacturing or global consolidation, but those features have little value if your business simply buys finished goods and sells domestically.

During demos, ask vendors to run your scenarios using realistic sample data. Watch how many manual steps are required and where custom development enters the process. A long feature checklist can hide awkward workflows. Process fit is more important than the total number of modules shown on a sales page.

Compare ERP, Inventory, and Operations Platforms Carefully

Not every product described as an “ERP” covers the same scope. Traditional or full-suite ERP platforms may combine finance, inventory, purchasing, order management, and other enterprise functions. Retail operations systems may focus more heavily on inventory and order workflows while integrating with separate accounting software.

For example, NetSuite is commonly evaluated as a broad ERP platform, while systems such as Cin7 may enter the conversation when inventory and product operations are the dominant need. The right category depends on the processes you want to centralize.

Use a comparison like this before narrowing the shortlist:

The table is directional, not a product guarantee. Always verify the exact modules, integrations, limits, and regional support for the products you are considering.

Calculate Total Cost Beyond the Subscription Fee

ERP cost includes much more than a monthly or annual license. Implementation services, data migration, integration work, custom reports, training, testing, support, internal staff time, and future administration can materially change the economics.

Start with a three-year view. Estimate software subscriptions, required modules, connector fees, implementation, customization, support, and the internal time of people who will define processes and test the system. Add a contingency for work discovered during migration.

Then compare that cost with the operational problem. If staff spend hundreds of hours each month reconciling orders and stock, automation has a measurable value. If errors create cancellations or expedited freight, include those costs. If better purchasing can reduce avoidable stockouts or excess inventory, model the potential impact conservatively rather than assuming an ideal result.

Avoid using revenue alone to justify ERP. A high-revenue business with simple operations may need less software than a lower-revenue company with complex supply chains.

The goal is not to prove that ERP pays for itself. It is to understand which costs are certain, which benefits are plausible, and which assumptions you need to validate before signing.

Implement Ecommerce ERP Without Breaking Daily Operations

Implementation is where a promising ERP project becomes either a reliable operating system or an expensive source of exceptions. A staged rollout, explicit data rules, and realistic testing reduce the risk.

Design the Integration Around Business Events

Instead of starting with a list of database fields, map the business events that must trigger data movement. Common events include product creation, inventory receipt, order placement, payment capture, shipment, cancellation, return, refund, and supplier receipt.

For each event, define what starts it, which system owns it, what data must move, and how quickly the receiving system needs the update. Inventory changes may need near-real-time synchronization, while some financial summaries can move on a schedule.

Consider an order cancellation. If the storefront cancels an order after the ERP already allocated stock, the integration must release that inventory and update the order state correctly. If a shipment has already been created, the cancellation may need manual review instead. This is why “orders sync” is not a sufficient integration requirement.

Also define idempotency, even if your technical team uses a different term. In plain language, the integration should avoid creating duplicates when the same message is received twice.

Good integration design focuses on business consequences. The question is not merely whether data arrived, but whether the next operational decision became correct.

Test Real Exceptions, Not Just Perfect Orders

A demonstration order with one product, one payment, and one shipment proves very little. Real ecommerce operations include partial shipments, cancellations, discount codes, gift cards, returns, exchanges, backorders, bundles, taxes, marketplace fees, address changes, fraud holds, and failed payments.

Build a user acceptance testing checklist from your actual order history. Select normal cases and difficult cases. Test a multi-item order fulfilled from two locations. Test a partial refund. Test receiving fewer units than a purchase order expected. Test a product that changes from sellable to damaged during a return.

For each scenario, verify the entire chain: storefront status, ERP record, warehouse action, inventory balance, customer communication, and financial effect. The result is only correct when all dependent systems agree.

Include users from operations, finance, customer service, purchasing, and fulfillment. Technical teams can confirm that an API call succeeded, but an accountant may notice that the transaction posted to the wrong account or a warehouse lead may see that the workflow creates an impossible picking step.

Testing exceptions before launch is usually cheaper than discovering them during peak sales.

Roll Out in Phases With a Clear Cutover Plan

A phased rollout reduces the number of unknowns your team must manage at once. You might begin with product and inventory synchronization, then orders and fulfillment, followed by purchasing, returns, and financial automation. The exact sequence depends on dependencies in your operation.

Create a cutover plan that defines the last transaction in the old workflow, the first transaction in the new workflow, opening inventory balances, open orders, open purchase orders, user access, and rollback conditions. Decide who has authority to pause the launch if critical reconciliation fails.

Avoid making unrelated process changes during the same week unless they are required by the ERP. Changing warehouse layout, shipping carriers, product codes, and accounting rules simultaneously makes it difficult to identify the cause of a problem.

You should also define a short list of launch metrics, such as failed integrations, inventory discrepancies, unprocessed orders, and financial posting errors. Review them frequently during the first operating cycles.

A controlled launch may feel slower than a “big bang,” but reliability is more important than speed when the system touches every order.

Before launch, give each role a short runbook for normal tasks and exceptions. Staff should know not only which screen to use, but also which downstream process their action affects and who owns escalation when a record fails.

Use ERP to Improve the Daily Ecommerce Workflow

Once ERP is stable, the most useful improvements come from using shared data to make routine decisions faster and more consistently. Inventory, purchasing, fulfillment, and finance are usually the first areas where sellers notice the operational difference.

Keep Inventory Accurate Across Channels and Locations

Inventory accuracy is often the highest-priority ecommerce ERP use case because almost every other process depends on it. The system needs a clear distinction between physical on-hand stock and the quantity customers are allowed to buy.

Available-to-sell inventory may subtract reservations, safety stock, damaged units, or stock assigned to another channel. If you sell through your own site, marketplaces, wholesale, and retail locations, the ERP can provide a coordinated inventory position while channel-specific rules determine what each channel sees.

Imagine a hypothetical brand with 100 units across two warehouses. Ten units are reserved for existing orders and five are quarantined after a quality check. Publishing “100 available” would be misleading. A properly designed availability calculation can expose a safer quantity to the storefront.

The challenge is timing. If stock changes in several places, synchronization must be fast enough for your sales velocity. During high-volume promotions, monitor integration latency and failed messages closely.

Do not treat inventory accuracy as a software-only metric. Cycle counts, receiving discipline, picking accuracy, and return inspection still determine whether the digital record reflects physical reality.

Improve Purchasing and Replenishment Decisions

ERP gives purchasing teams a better foundation because demand, current stock, open sales orders, incoming purchase orders, supplier lead times, and product costs can be analyzed together. That does not make forecasting perfect, but it reduces decisions based on isolated spreadsheets.

Start with simple replenishment logic. Define a reorder point using expected demand during supplier lead time plus an appropriate safety-stock buffer. Then review whether seasonality, promotions, minimum order quantities, or unreliable suppliers require adjustments.

For example, a product selling steadily may appear safe with four weeks of stock. If its supplier requires eight weeks from order to receipt, the business is already exposed. ERP planning can make that risk visible earlier when lead times and open purchase orders are maintained accurately.

Avoid automating purchase orders before the inputs are trustworthy. Incorrect lead times or supplier pack sizes can generate equally incorrect recommendations at greater speed. Use suggested purchase quantities as decision support first, then add approvals or automation as confidence grows.

Purchasing becomes much more useful when teams also review excess stock. ERP should help you identify inventory that is tying up cash, not only products at risk of running out.

Connect Fulfillment, Shipping, Returns, and Finance

Orders do not end when a label prints. A complete ecommerce workflow needs fulfillment status, shipping costs, returns, refunds, and financial records to stay connected. That is where ERP can reduce the manual reconciliation that often appears after sales grow.

Some businesses use dedicated shipping software such as ShipStation alongside ERP. In that structure, the ERP can remain the operational record while the shipping system specializes in carrier selection, label creation, and shipment execution. The important design question is which system creates the fulfillment instruction and which status is authoritative.

Returns require similar clarity. A returned item may go back to sellable stock, quarantine, refurbishment, or write-off. The inventory and financial treatment should reflect the actual condition instead of automatically restocking every return.

Finance also needs to account for discounts, taxes, refunds, payment processor settlements, and marketplace fees. ERP can organize the transaction flow, but reconciliation rules must match how money actually moves.

A mature setup closes the loop: the operational event and its financial consequence remain connected from order through final settlement.

Avoid Common Ecommerce ERP Mistakes and Fix Problems Systematically

ERP problems are rarely caused by one dramatic failure. More often, small data, process, or integration issues accumulate until people stop trusting the system. Strong troubleshooting starts by separating symptoms from root causes.

Do Not Automate an Undefined Process

One of the most expensive mistakes is automating a workflow that different teams understand differently. If sales, warehouse, and finance each define “order complete” in a different way, the ERP cannot create consistency without an agreed rule.

Before automating, define the trigger, decision, owner, and expected outcome. For example: when a paid order passes fraud review, inventory is allocated; when fulfillment confirms shipment, the storefront receives tracking; when a return is inspected, stock moves to the correct condition and finance receives the refund status.

Keep manual approval where judgment is still required. High-value refunds, unusual B2B terms, or inventory adjustments may deserve review until the team has enough data to create reliable rules.

Watch for “shadow systems” after launch. If staff export data to private spreadsheets because they do not trust ERP reports, find out why. The report may be missing a field, the data may be late, or the team may not understand the new definition.

Automation is successful when it removes unnecessary decisions without hiding important exceptions. A faster bad process is still a bad process.

Trace Sync Errors From Source to Destination

When records disagree, start with one transaction and follow it through the system chain. Do not immediately run a bulk resync because that can create duplicates or overwrite correct data.

Use a simple troubleshooting sequence:

1. Confirm the source record: Check whether the originating system contains the expected value and timestamp.
2. Check the integration event: Verify that a message, API call, batch job, or connector run was triggered.
3. Inspect transformation rules: Make sure fields, units, taxes, currencies, statuses, and identifiers were mapped correctly.
4. Verify the destination: Confirm whether the receiving system accepted, rejected, or modified the record.
5. Reconcile downstream effects: Check inventory, fulfillment, customer status, and finance before closing the issue.

Document the error type and root cause. If the same failure appears repeatedly, the fix belongs in the process or integration, not in a growing manual checklist.

Also distinguish latency from failure. A five-minute delay may be acceptable for one data type and disastrous for another. Define expected synchronization windows so teams know when to wait and when to escalate.

After go-live, protect data quality with required master-data fields, sensible permissions, and recurring reconciliation. That prevents new SKUs, suppliers, locations, or manual adjustments from slowly rebuilding the inconsistencies you cleaned up during migration.

Measure ERP Performance and Scale Only What Works

After launch, ERP should be managed as an evolving operating system. Measurement helps you distinguish genuine improvement from automation that merely moved work somewhere less visible.

Track Metrics That Reflect Operational Outcomes

Choose metrics that connect ERP performance to business operations. System uptime matters, but it does not tell you whether orders are flowing correctly or inventory can be trusted.

Useful measures can include order import failure rate, inventory discrepancy rate, percentage of orders requiring manual intervention, fulfillment cycle time, purchase-order receiving accuracy, return-processing time, reconciliation exceptions, and days required to close financial periods. The right set depends on the problems that justified the project.

Establish a baseline from the old process whenever possible. If you do not know how many orders required manual correction before ERP, you cannot confidently say the new workflow improved the situation.

Separate system metrics from business metrics. Integration latency is a system metric. Overselling is a business outcome. Tracking both helps you understand cause and effect.

Avoid building a dashboard with dozens of measures nobody owns. Assign an owner and target or acceptable range to each critical metric. When a measure deteriorates, the owner should know which process to investigate.

Measurement is most useful when it leads to a decision, not when it simply creates more reporting.

Use repeated exceptions as your optimization queue. If staff keep overriding the same allocation rule or correcting the same import, fix the rule or data before buying another module. Expand the ERP only when a specific bottleneck, expected improvement, and success measure are clear.

Scale to More Channels, Warehouses, and Entities Deliberately

ERP becomes particularly valuable when complexity grows in dimensions, not just volume. A second warehouse introduces transfer rules and stock allocation. A marketplace introduces fees, settlement timing, and channel inventory. A new country may introduce currencies, taxes, legal entities, and financial reporting requirements.

Do not assume a process designed for one location will scale unchanged. Before adding a new channel or warehouse, test the full workflow: product setup, inventory visibility, order routing, fulfillment, returns, customer service, reconciliation, and reporting.

Use templates where processes genuinely repeat, but preserve controlled differences. A warehouse may need different carrier rules, while financial account structures should remain standardized. A wholesale channel may use different pricing and payment terms without requiring a separate product master.

Capacity planning also matters. Review API limits, connector throughput, batch schedules, reporting performance, and operational staffing before a major volume increase or peak season.

If you eventually evaluate broader enterprise platforms such as SAP, the same principle still applies: scale should solve a defined operating requirement. More sophisticated software cannot compensate for unclear ownership, poor data, or uncontrolled process variation.

Decide Whether Ecommerce ERP Is Your Next Step

Understanding ecommerce ERP and how it works is useful only if it helps you make a better operational decision. ERP connects the records and workflows behind ecommerce so inventory, orders, purchasing, fulfillment, and finance can operate from coordinated data. That can be extremely valuable when growth has created cross-functional complexity, but it is unnecessary when a simpler stack still works reliably.

Start by documenting your real bottlenecks, mapping your critical workflows, cleaning master data, and defining which system should own each record. Then evaluate products against realistic scenarios rather than feature lists. If you implement, test exceptions as carefully as normal orders and measure operational outcomes after launch.

The right next step may be a full ERP, a focused operations platform, or simply better integration between the tools you already use. Choose the smallest architecture that solves today’s problems without blocking the complexity you can reasonably expect tomorrow.

Juxhin

I’m Juxhin, the voice behind The Justifiable.
I’ve spent 6+ years building blogs, managing affiliate campaigns, and testing the messy world of online business. Here, I cut the fluff and share the strategies that actually move the needle — so you can build income that’s sustainable, not speculative.

Related posts:

How to Use Dsers Shopify for Seamless Dropshipping How To Sell Digital Downloads With SendOwl (Beginner Guide) How Much Can An Ecommerce Store Make? Real Numbers And Profit Examples How To Set Up Ecommerce CRM: 9 Simple Steps for a Smoother Launch How Much Money Can Ecommerce Automation Make? Honest Pros, Cons, and Profit Potential How Much Can An Ecommerce Website Make? Real Numbers Revealed