What does scrap metal ERP include?

ERP stands for enterprise resource planning. In scrap and recycling, the useful definition is broader than accounting and narrower than "every piece of software in the company." It is the operating architecture that connects core workflows and gives each important record an authoritative home.

For a recycler, that architecture commonly includes five layers:

A small operator may run several of these layers in one product. A larger or more specialized recycler may use separate systems connected by integrations. The right test is not whether the company has one login. It is whether every critical record has one clear owner and moves through a controlled workflow.

Yard-side systems control material transactions

The yard-side system begins when material arrives. Its job is to turn a physical load into a traceable purchase, inventory movement, or shipment.

Seller and supplier identity

The first record is the party delivering or selling material. Depending on the transaction and jurisdiction, the yard may need identity, vehicle, payment, photograph, signature, hold-period, or reporting information. Requirements vary by state and locality, so configuration should follow the yard's legal review rather than a generic national template.

The system should prevent a clerk from bypassing required fields simply to move the line faster. It should also retain the original evidence and the person who captured or changed it.

Scale and ticket workflow

A scale transaction usually needs more than gross, tare, and net weight. A controlled ticket can include:

• scale or device identifier
• date and time for each weighing
• vehicle, trailer, or container identity
• gross, tare, and calculated net weight
• unit of measure
• material and grade
• buyer or scale operator
• price, deductions, and reason codes
• linked photographs or inspection notes
• ticket number and approval history

NIST Handbook 44 is the current federal model standard for weighing and measuring devices, while states decide how those requirements are adopted and enforced. Software does not make a scale legal for trade. It should preserve the data and controls needed to support the yard's approved weighing process.

Grading, pricing, and purchasing

The yard must connect the measured load to the commercial decision. That means recording the commodity or grade, applied price, deductions, purchase total, and any approval required for an override.

A price table can speed up routine purchasing, but it should not remove accountability. The system should show which price was active, who changed it, when the change took effect, and why a ticket departed from the normal rule.

Inventory and outbound sales

Once purchased, material becomes inventory or moves into a processing stream. The yard-side record should support the level of traceability the business actually manages, such as commodity, grade, location, package, heat, bundle, or weight pool.

Outbound sales then reduce that inventory and connect shipment details to the customer order, bill of lading, scale records, and invoice. The goal is not a false promise of perfect physical precision. It is a repeatable reconciliation between what the yard bought, processed, held, sold, and shipped.

Hauling-side systems control customer and container work

Hauling begins with a service commitment outside the scale house. The primary record is a job tied to a customer, site, asset, truck, driver, schedule, and proof of work.

This is a different operating domain from scrap purchasing.

Customer, site, and service setup

A hauling record should separate the billing customer from the service location. Each site may have access instructions, service windows, contacts, material restrictions, container placement notes, and agreed charges.

Recurring work should be structured as a schedule, not hidden in a notes field. One-time deliveries, swaps, pulls, relocations, and returns should remain distinct job types so dispatch, drivers, and billing interpret them the same way.

Container history

A container is both a physical asset and part of a service promise. Its history should show:

• current location and status
• customer and site assignment
• delivery, swap, pickup, and return events
• associated job and driver
• contents or service type when relevant
• photographs, notes, signatures, and timestamps
• maintenance or out-of-service condition

The important control is event history. Editing the current location must not erase how the container got there.

Dispatch, routing, and driver execution

Dispatch turns scheduled work into a day plan. It assigns the job, truck, driver, container, and sequence, then records changes as conditions shift.

Routing can help sequence work, but the dispatcher still needs to account for container availability, truck type, yard and customer hours, disposal or processing destinations, traffic, driver availability, and urgent changes. Where federal hours-of-service or electronic logging rules apply, the ERP or dispatch plan does not replace the carrier's compliance process.

The driver app should return structured evidence: arrived, delivered, swapped, picked up, failed, photographed, signed, and completed. A completed job can then support billing without requiring office staff to reconstruct the day from calls and paper tickets.

Where CRO fits in the decision

CRO fits at the hauling and container-operations layer. It can connect customer sites, container and per-unit records, dispatch, driver proof of service, completed work, field-to-invoice billing, and the approved handoff to QuickBooks.

CRO is not the yard-side ERP, certified scale system, material inventory ledger, or general ledger. A recycler still needs those systems to own weighing, grading, purchasing, material value, inventory, posting, tax, and financial reporting where applicable.

The architecture decision is therefore about ownership and reconciliation. Define which system owns the customer, container, job, scale ticket, material transaction, invoice, and accounting entry, then test the handoffs and exception queues between the yard, hauling, and accounting systems.

One load can create records in several systems

Consider a customer who requests a container, fills it with material, and schedules pickup.

1. The hauling system creates the customer job, assigns the container, and dispatches the truck.
2. The driver records delivery and pickup events, photos, timestamps, and any approved service exception.
3. The yard-side system records the inbound scale transaction, material grade, purchase or receipt terms, and inventory movement.
4. An approved hauling charge and an approved material transaction move to accounting according to the designed integration.
5. Accounting posts the financial entries, applies payments or credits, and completes reconciliation.
6. Exception reports identify missing scale pairs, unmatched jobs, duplicate exports, overrides, or transactions waiting for approval.

No system should silently invent the record owned by another. An integration should carry a stable identifier so staff can trace the accounting entry back to the job or ticket that created it.

Accounting controls belong in the design

Accounting integration is not complete when a file exports successfully. The design should answer who can create, approve, transfer, change, and reconcile each transaction.

Useful controls include:

• separate permissions for entering and approving price overrides
• unique source identifiers on exported purchases and invoices
• locked periods or controlled reopening procedures
• duplicate detection before and after transfer
• daily or weekly reconciliation between source totals and accounting totals
• exception queues for rejected, edited, or unmatched transactions
• audit history for customer, vendor, bank, tax, and general-ledger mapping changes
• documented responsibility for credits, voids, refunds, and reissued payments

The accounting platform should remain the authority for the chart of accounts, posting, tax treatment, period close, and financial statements. The yard and hauling systems should retain the operational detail that explains why each approved financial transaction exists.

How to implement scrap metal ERP

Implementation is a business-process project with software inside it. Microsoft Dynamics 365 implementation guidance is product-specific, but its core disciplines apply broadly: data governance, test strategy, user acceptance, cutover planning, training, security, support, and migration readiness.

1. Map the current workflows

Document what actually happens, including workarounds. Follow representative transactions from request or arrival through approval, billing or settlement, accounting, and reconciliation.

Include exceptions such as a broken scale, rejected load, changed grade, price override, container at the wrong site, failed pickup, duplicate customer, offline driver, returned payment, and disputed ticket.

2. Assign a system owner to every record

Create a data-ownership matrix before configuring integrations. Decide which system owns customers, sites, sellers, suppliers, commodities, grades, prices, trucks, containers, jobs, scale tickets, inventory, invoices, payments, and the general ledger.

Also decide which fields may be copied and which may be edited only in the source system.

3. Clean master data

Normalize customer and supplier names, addresses, tax settings, material codes, container IDs, truck IDs, chart-of-accounts mappings, and open balances. Merge duplicates deliberately. Do not migrate every old note simply because it exists.

Use data stewards from the yard, dispatch, accounting, and management teams. The people who understand the records should decide what is accurate, active, and required.

4. Design integrations and exception handling

For each interface, define direction, timing, identifiers, required fields, validation, retry behavior, duplicate handling, and ownership of failures.

A successful transfer is only one path. The design also needs a visible queue for rejected records, changed records, partial failures, and corrections.

5. Run test migrations

Migrate a representative copy of customers, suppliers, materials, assets, open jobs, open tickets, open receivables, and opening balances. Reconcile record counts and financial totals. Then let users run real scenarios against the converted data.

Repeat the process until the team can predict duration, validate results, and resolve failures within the cutover window.

6. Pilot an end-to-end operating slice

A useful pilot is not a demo with perfect sample data. Choose one yard, scale lane, commodity family, customer group, dispatch team, or route set. Process work from the first operational event through accounting reconciliation.

Measure exceptions, not only speed. The pilot should reveal missing permissions, unclear ownership, duplicate records, weak training, and integrations that fail under normal changes.

7. Prepare cutover and fallback

The cutover plan should name the final data freeze, last legacy transactions, migration sequence, validation owners, go or no-go criteria, communication plan, support coverage, and fallback decision.

Do not shut down the old process until required balances, open work, asset locations, and critical integrations are reconciled.

8. Reconcile after launch

For the first days and weeks, review source-to-accounting totals, unprocessed exceptions, missing container events, scale ticket sequences, overrides, inventory variances, and user access. Assign every exception to an owner and track it to closure.

How system needs change with company size

A single-location yard with limited hauling may prioritize fast ticketing, compliant seller records, basic inventory, accounting handoff, and a simple dispatch board.

A multi-yard recycler needs consistent material definitions, controlled location-specific prices, intercompany or inter-branch processes, centralized customer and supplier governance, cross-yard inventory visibility, and consolidated reporting.

A hauling-heavy scrap operator needs stronger customer-site records, container event history, route planning, driver proof, telematics context, and job-to-invoice controls. It may still depend on a separate yard platform for scale and commodity accounting.

A regional or enterprise recycler may add formal master data management, integration monitoring, role-based security, data warehouse reporting, disaster recovery, and phased releases. More scale creates more reasons to separate system ownership, not fewer.

Questions to ask before selecting or implementing a system

• Which system owns the legal or commercial scale ticket?
• Can staff trace gross, tare, net, grade, price, approval, and payment back to one transaction?
• Does container history preserve every movement instead of only the latest location?
• How are dispatch changes and failed services recorded?
• What happens when a yard ticket and hauling job do not match?
• Which transactions move to accounting, in which direction, and at what approval point?
• How are duplicate exports, rejected records, credits, voids, and corrections handled?
• Can each yard use local operating rules without breaking company-wide reporting?
• What data will be cleansed, migrated, archived, or intentionally left behind?
• Which end-to-end scenarios must pass before cutover?

Frequently asked questions

About the author

Ellery Curran
Marketing Specialist, RapidWorks

Ellery creates practical resources for waste, recycling, and site service operators evaluating software for dispatch, field work, billing, and growth.