Cubing software is the processing and integration layer between a dimensioning hardware sensor and your logistics management systems. When a laser, camera array, or structured-light sensor captures the length, width, and height of a package or pallet, that raw data has no operational value on its own. Cubing software converts those measurements into structured records, applies business rules (DIM weight calculation, freight class assignment, compliance thresholds), and delivers the result to WMS, TMS, or ERP platforms—typically within 200–500 milliseconds of the scan.
The hardware captures. The software makes the data actionable.
Modern dimensioning hardware uses one of three primary sensing technologies:
Each technology produces a point cloud or depth map—a three-dimensional model of the scanned object. Cubing software converts this raw geometric data into a minimal bounding box: the smallest rectangular volume that fully contains the object. That bounding box becomes L × W × H in the records your systems consume.
A complete cubing software pipeline runs these stages on every scan:
The raw sensor output (millions of data points in 3D space) is filtered to remove noise, floor plane, and background objects. Outlier removal algorithms eliminate false points that would inflate the bounding box. This stage runs in 50–150 ms depending on scan volume and processor speed.
The software fits the tightest possible rectangular box around the filtered point cloud. For irregularly shaped freight (odd-shaped packages, shrink-wrapped pallets with protruding items), the algorithm determines the axis-aligned bounding box—the industry-standard approach for freight billing.
Raw dimensions enter a rule engine where the software applies:
The dimension record is enriched with contextual data captured at the same measurement point: barcode scan (tracking number, item ID, PO number), weight scale reading, timestamp, operator ID, and station ID. This creates a single complete transaction record per item.
The enriched record is delivered to downstream systems via API, flat file, or direct database write. Delivery latency from scan completion to system update is typically under 500 ms in API integrations.
Cubing software connects to logistics systems through four primary integration methods:
The most common integration for modern WMS and TMS platforms. The cubing software sends a JSON payload to a configurable endpoint immediately after each scan. Supports real-time updates with sub-second latency. Requires the receiving system to expose a webhook or REST endpoint.
For legacy WMS platforms that lack API endpoints, cubing software writes directly to a shared database table or staging table. The WMS polls or triggers on table updates. Latency depends on poll interval (typically 1–30 seconds).
Batch export of dimension records to CSV, XML, or EDI format. Used in high-volume scenarios where real-time integration is not required and batch reconciliation is acceptable. Common in end-of-shift manifest generation.
Several major WMS platforms (Manhattan Associates, Blue Yonder, SAP EWM) support certified partner integrations where the cubing software vendor provides a native connector. These connectors eliminate custom development and are tested against specific WMS versions.
The data payload a downstream system receives from cubing software contains:
This complete record eliminates the need for manual data entry at any point in the receiving or outbound process.
Cubing software is not a fixed-logic system. Operators configure it to match their specific business rules:
For cubing software to be used in revenue-generating applications (carrier billing, freight class assignment), the full dimensioning system (hardware + software) must meet accuracy certification standards:
A dimensioning system that passes hardware accuracy tests but uses non-certified software does not qualify for carrier billing programs. The software accuracy standard—bounding box calculation correctness, rounding logic, and DIM factor application—is tested independently from the hardware sensor.
Cubing software operates in two deployment architectures depending on throughput requirements:
Each scan triggers immediate processing and integration output. Required for:
Scans are queued and processed at intervals (end of shift, end of day). Suitable for:
Operators scan each inbound package through a static dimensioner at the receiving dock. Cubing software captures dimensions + weight + barcode, posts the complete receiving record to the WMS within 300 ms, and the WMS auto-generates a license plate and directed putaway task. No manual dimension entry. No re-measurement disputes with clients.
On a high-speed conveyor (3,600 parcels/hour), the dimensioner captures each item at line speed. Cubing software processes in under 150 ms and sends the dimension record to the sorter controller, which uses it to confirm the correct sort lane based on carrier and service level. Oversize items trigger immediate divert to an exception lane.
At a freight terminal, pallets are measured by a drive-through scanner. Cubing software calculates chargeable weight (higher of actual vs. DIM weight), assigns freight class by density, and posts to the TMS freight audit module. The TMS generates the corrected invoice automatically, eliminating manual re-weigh and re-cube disputes.
No. Cubing software is typically developed and certified for specific hardware sensors. The point cloud format, data interface protocol, and accuracy calibration are tightly coupled between hardware and software. Some vendors offer SDK-based integration for third-party hardware, but this requires technical validation and may not maintain certification compliance.
Well-designed cubing software includes confidence scoring on each scan. If the system cannot produce a high-confidence bounding box (due to reflective surfaces, transparent packaging, or irregular shapes that the sensor cannot fully capture), it flags the item as an exception rather than posting an inaccurate dimension record. Exception items route to manual measurement or re-scan workflows.
Yes. Most enterprise cubing software maintains a local database of all scan records with timestamps, operator IDs, and image captures. This historical archive supports freight audit (verifying billed dimensions match measured dimensions), dispute resolution, and operational analytics.
All commercial cubing software uses the axis-aligned bounding box as the standard output regardless of object shape—this matches how carriers calculate DIM weight. A cylindrical drum is measured as the smallest rectangle that fully contains it. Irregular shapes are bounded by the maximum extent in each axis. This is the industry-standard approach aligned with carrier billing rules.
A standard REST API integration between cubing software and a modern WMS takes 2–4 weeks: 1 week for API endpoint development on the WMS side, 1 week for cubing software configuration and field mapping, 1 week for testing in a staging environment, and 1 week for parallel-run validation (comparing cubing software output against manual measurements to verify accuracy before go-live).