BulkTally Yard grew out of software built for a working bulk material operation in the Uinta Basin. This anonymized implementation study explains the operational requirements and the product behavior they produced. It does not publish customer records, imply a customer endorsement, or claim unmeasured time or cost savings.
The operational problem.
A yard needs more than a ticket archive. Operators must associate movements with the correct storage unit, distinguish work in progress from completed loads, and explain on-hand inventory. The office needs the completed documents and reports. Customers need access to their own records without seeing anyone else's activity.
The implementation needed those views to agree on what a completed load meant. A ticket still being prepared could not safely be treated as an inventory movement.
The workflow that was built.
The application connects storage units to signed weight lines on bills of lading. Operators prepare a draft, review the ticket, and finalize it. Finalized movements feed the inventory calculation, the daily log, and reports. The ticket can produce a printable bill of lading PDF.
On-hand is calculated from a baseline plus finalized signed movements. Calibration records a reason for adjusting the physical balance. Ticket and administrative activity have an audit history so the explanation is not lost when staff change shifts.
What we can demonstrate and measure.
On September 17, 2026, we checked the yard product's automated BOL, inventory, and customer-scope tests using an isolated test database. All 43 checks passed. They exercise the application rather than estimating a customer's business results:
- Signed movement: a test adding 30,000 units and subtracting 10,000 units expects a 20,000-unit balance.
- Storage-level effects: the tests check that ticket changes update the related storage calculation.
- Draft exclusion: a draft does not appear in the finalized storage history.
- Customer separation: scope tests check access to the relevant company's records.
These are software acceptance checks, not production throughput, a security certification, or a promise of the same business outcome at every yard. We have not established a publishable before-and-after measurement of labor savings or billing speed for this study.
Why the distinction between draft and final matters.
A prepared ticket can change before the truck leaves. Treating it as final would make stock appear to move before the operator committed the load. The explicit finalization step gives the workflow a clear point at which weight lines become inventory movements.
The same rule carries into reconciliation. Staff can compare a storage balance with finalized tickets instead of mixing planned and completed work. When a physical measurement differs, a recorded calibration explains the adjustment instead of disguising it as a shipment.
Give customers a view of their own work.
The customer portal provides access scoped to a company. This requirement is enforced on the server, not just by hiding rows in the interface. The public demo uses fictional records to show that experience without exposing a customer's operating information.
What transfers to another operation.
The reusable product is the storage, ticket, reporting, and access workflow. Company branding, products, units, storage names, and ticket prefixes are configuration. A new report, data migration, integration, or materially different process needs its own scope and acceptance checks.
This is also why a custom TMS is a separate engagement: transportation workflows can extend well beyond a yard's inventory and BOL requirements. The existing yard product is evidence of implemented software, not a claim that every transportation feature is already included.
Review it yourself.
Open the BulkTally Yard demo to inspect fictional records, read the reconciliation guide, or explore the yard product and implementation process. Demo records reset periodically; they are not a production record of customer results.
