Delivery Tickets from Construction Supplier Invoices to Excel

A monthly construction supplier invoice from a bulk-materials supplier — an aggregate quarry, a regional ready-mix plant, an asphalt producer — almost never arrives as a single-page bill. It arrives as a summary cover (supplier, customer account, billing period, totals by material) followed by N attached per-load delivery, scale, or batch tickets. One ticket per truckload. The summary tells you what the supplier wants you to pay; the ticket pages are where the data you actually need for job costing, reconciliation, and AP posting lives.

The extraction outcome that makes that data usable is one row per ticket, keyed on ticket number, with ticket date, job or PO reference, material, quantity, unit (tons, CY, or loads), unit price, and line total. That row schema lets contractors run job costing, reconcile against field copies, and post AP from a single spreadsheet. It is also what lets you extract delivery tickets from construction supplier invoice to Excel in a shape your job-cost system, your accountant, and your reconciliation against the foreman's field copies can all consume from the same workbook.

Scale matters here, because per-ticket extraction is only worth the effort at the volumes contractors actually see. A single month's bill from a regional aggregate quarry or ready-mix plant can run anywhere from 40 to 400 ticket pages, depending on contractor size and project mix. A mid-sized GC processing 5 to 30 such supplier invoices a week is routine. Manual per-ticket entry across that volume is the grind every construction AP team is trying to retire.

Paper and PDF are still the baseline contractors must process today. The FHWA's EDC-6 e-Ticketing initiative for construction materials delivery tracks ten state departments of transportation — Alabama, Florida, Iowa, Kentucky, Minnesota, Missouri, North Dakota, Pennsylvania, Utah, and Virginia — actively applying e-Ticketing for asphalt, concrete, and aggregate deliveries on state-funded work. The other forty states are still on paper, and even in the pilot states the e-tickets cover state DOT projects rather than private-sector deliveries. For most contractors, scale ticket data extraction from supplier invoice PDF documents is the workflow that has to work right now, not the one a future e-ticketing standard might eventually replace.

The scope this article works within is per-ticket extraction itself — what each ticket carries across aggregates, ready-mix, and asphalt; the spreadsheet schema that holds the rows; the reconciliation against field copies; the per-job rollup; and where a prompt-based extraction tool fits against the closed construction-AP products you've probably already seen in the SERP. GL coding decisions, three-way matching against purchase orders, and integration with construction ERPs sit downstream of the spreadsheet and belong to the AP and job-cost systems that consume it.

What each per-load ticket carries — and where aggregate, ready-mix, and asphalt diverge

Across material types, every per-load ticket carries roughly the same skeleton. The fields you can expect on almost any ticket page:

• Ticket number — the unique identifier the supplier's dispatch or scale-house software assigned to that load. This is the deduplication key for the whole workflow.
• Ticket date and time — when the load was loaded out, weighed, or batched. Sometimes both load time and dispatch time appear; the load time is the billable event.
• Job number or PO reference — the field your dispatcher or driver gave the scale operator or batch plant. This is the field that lets per-ticket allocation roll up by job.
• Supplier and plant or quarry of origin — the parent supplier (Vulcan Materials, Martin Marietta, CRH, Holcim) plus the specific plant or quarry that produced the load. Same supplier, multiple plants is the norm.
• Material code and description — usually a supplier-internal code plus a short description (#57 stone, 4000 PSI mix, SP-9.5 surface course).
• Quantity, unit, unit price, line total — the billable values. Line total is sometimes on the ticket and sometimes applied at the invoice cover; if the supplier prices monthly, the ticket may show only quantity and unit.
• Tax and freight — usually applied at the invoice level, occasionally per ticket when freight is variable by haul distance.
• Truck or driver identifiers — truck number, driver name, sometimes a signature line.

That's the shared skeleton. The material-specific fields layered on top are where the per-supplier prompt has to get specific.

Aggregate hauler tickets carry net tons calculated from gross-tare scale weights — the gross weight of the loaded truck, the tare weight of the empty truck, and the net tons billed. Net tons is the billable quantity; gross and tare are the inputs you may or may not want to extract depending on whether you audit the weights. A scale-house signature or stamp confirms the weighing. Haul distance often appears separately when the supplier bills freight per ton-mile or charges a haul surcharge for distant jobs. CDL or DOT driver numbers sometimes appear for compliance tracking, especially for state DOT projects. For a full treatment of the aggregate-supplier workflow, the aggregate hauler invoice and haul-ticket extraction deep-dive walks the quarry-bill shape and the ton-mile reconciliation in detail.

Ready-mix concrete batch tickets are governed by ASTM C94 — the Standard Specification for Ready-Mixed Concrete — which prescribes the data the batch ticket must carry. Expect to see the mix design identifier, cubic yards delivered, batch time, plant of origin, the cement and aggregate weights actually batched, the admixtures used, and a slump value if measured at the plant. The water-add fields are the ones that bite at reconciliation: water added on site by the driver at the contractor's request, with a signature acknowledging the add, can change the mix's water-cement ratio in ways the QC engineer cares about. Those fields matter for both billing accuracy and for the project's concrete quality records. The ready-mix concrete batch ticket extraction deep-dive covers the ASTM-mandated fields and the batch-ticket-to-mix-design audit in full.

Asphalt load tickets carry tons (always tons, never CY for hot-mix asphalt), a mix code that usually references a state DOT mix specification (Superpave designations like SP-9.5, SP-12.5, SP-19, or state-specific equivalents), plant timestamp, and a load number sequence used for compaction QC on the paving operation. Load temperature appears on tickets for projects where the spec requires it — temperature at the plant matters because asphalt cooled below the compaction range can't be laid to spec, and the load-number-plus-timestamp combination is what the paving foreman cross-checks against the roller pass record. Asphalt is the material that most often lacks a sibling deep-dive on most sites, so an asphalt load ticket extraction from supplier invoice prompt should explicitly name tons, mix code, load number, plant timestamp, and (where relevant) load temperature alongside the shared per-ticket fields.

The pattern across all three: the same per-load ticket shape with material-specific columns layered on top. A prompt designed for a single contractor's mix of suppliers names the shared columns once and adds the material-specific columns the suppliers actually print on their tickets.

The per-ticket spreadsheet schema for job costing, reconciliation, and AP posting

One row per ticket. That rule decides everything else about the schema, because the downstream uses — pivoting by job, joining against field copies, posting line items into AP — all assume the row is the atomic unit and the ticket number is the row key.

The required columns, and what each one earns:

• Ticket number. The deduplication key. Without it, you cannot reliably detect duplicates across months, you cannot key a row-level reconciliation against field copies, and you cannot match a line on the AP screen back to a specific load. This is the column the whole workflow depends on.
• Ticket date. When the load was delivered, not when the supplier invoiced. Job costing books to the period the work happened in, and a ticket dated late in the month on an invoice posted the following month belongs in the prior period's WIP.
• Job or PO reference. The field that drives per-ticket allocation. If the dispatcher coded it at the plant, great; if the field is blank or wrong, the prompt should leave it visible rather than guessing.
• Supplier and plant of origin. Two columns, because the same supplier routinely bills from multiple plants and the plant column is what distinguishes them for multi-plant reporting and for tracing back to which quarry or batch plant produced a specific load.
• Material code and material description. Keep them separate. The code is what your job-cost system reconciles against; the description is what a human reads.
• Quantity and unit, as separate columns. This one is easy to miss and expensive to get wrong. Aggregating across mixed units (tons, CY, loads) without a unit column fails silently — the spreadsheet adds the numbers and produces a total that means nothing. A separate unit column lets pivots and rollups stay correct across mixed materials.
• Unit price and line total. Some tickets carry both. Others carry only quantity, with pricing applied at the invoice cover. The prompt should lift line total from the ticket where it's printed and compute it from quantity times unit price where it isn't — and the schema should make clear which case applied so a reviewer can trace back.
• Tax and freight allocation. Both are usually applied at the invoice level. Two patterns work: allocate proportionally to each ticket so per-ticket line totals match the invoice total exactly, or carry tax and freight as separate rows (or separate columns on a totals row) and reconcile against the invoice cover. Pick one per supplier and stay consistent.
• Audit column with source PDF page reference. The column that lets anyone reading the spreadsheet open the original PDF to the exact ticket page in seconds. This is the difference between a spreadsheet a controller can spot-check and one they have to take on faith.

Optional columns earn their place when the workflow needs them:

• Truck or driver ID when you dispute loads and need to identify which haul it was.
• Haul distance when freight varies by distance and you need to verify the supplier's distance calculation against the job address.
• Mix design for ready-mix, when the QC engineer needs the mix-design audit trail alongside the billing record.
• Load number for asphalt, when you're cross-referencing tonnage delivered against compaction QC records.
• Reconciliation status — matched, unmatched, or disputed — as the status column you update during the field-copy reconciliation step.

This schema works because it's the universal interchange format. The same per-ticket rows feed Excel pivot tables for monthly close, CSV imports into job-cost systems, and JSON for any custom AP automation a team has built around its own ERP. Treating the schema as the workflow boundary — and not the workflow product — is what lets you convert construction materials supplier invoice tickets to Excel without locking yourself into a single tool's idea of how the downstream should work.

Reconciling invoice tickets against field copies, including ticket-number duplication

There are two ticket sources, and the reconciliation lives at the intersection. The supplier-invoice tickets arrive once a month, attached to the bill, in order to be paid. The field copies arrive throughout the month — paper carbons handed back at delivery, photos texted in by the foreman, sometimes a digital ticket from a supplier portal — and get entered into the contractor's job-cost system as quantities consumed on a specific job. The reconciliation question every month is whether every ticket the supplier is billing for was actually received in the field, at the matching quantity, against the right job.

Per-ticket extraction turns that question from a header-total sanity check into a row-level join keyed on ticket number. The practical consequence is the kind of error a header total hides: a 200-ticket monthly bill whose summary footer sums correctly to the penny can still hide three tickets the foreman never received and one ticket the supplier billed twice. The header total is right because the supplier's accounting system is internally consistent — not because every line on it is real. A row-level extraction with one row per ticket surfaces both the missing loads and the duplicates as exceptions a clerk can investigate, rather than as a discrepancy that only appears at month-end job-cost review when the field quantities don't match the AP totals.

Ticket-number deduplication is worth treating explicitly because duplicate ticket numbers happen often enough to design for. The recurring causes are predictable: the supplier re-bills a previously disputed load — the original ticket was credited two months ago, the load actually delivered, and the rebill carries the same ticket number; a ticket-printer roll resets and the same sequence prints again on a different truck; a plant reuses a ticket-number range after year-end. A row-level extraction with ticket number, ticket date, plant of origin, and supplier carried as separate columns lets the contractor catch the duplicate at AP review by sorting on ticket number across the trailing few months. Once spotted, the resolution is straightforward — confirm against the field copy whether the load delivered once or twice, credit accordingly. The cost of missing it is a paid duplicate that only surfaces in an annual cost audit.

The reconciliation status column is what makes the workflow operational. Three states cover almost every case:

• Matched — the ticket on the bill matches a field copy with the same job/PO and quantity. No action needed; the row posts as billed.
• Unmatched — the ticket appears on the bill with no corresponding field copy. Flag the row for the foreman to confirm the load delivered (in which case it becomes matched) or to contest (in which case it becomes disputed).
• Disputed — quantity or job-coding mismatch between bill and field copy. Hold the row pending supplier resolution; partial-pay the rest of the bill and chase the dispute on its own track.

The full process of approving contractor invoices against field tickets covers the AP-approval mechanics around the matched/unmatched/disputed flow in more depth, including the document trail that has to follow a disputed load through to credit.

Worth naming what this is not: this reconciliation is the contractor's own job-cost-side check, supplier-invoice tickets against the field copies the foreman submitted. It is not three-way matching against a purchase order, which some contractors run as a separate workflow upstream of AP. Three-way matching answers "did the PO authorise this purchase?"; field-ticket reconciliation answers "did the work the supplier is billing for actually happen on the job site, at the quantity billed?" Both checks have a place; the bulk materials invoice reconciliation against tickets is the one that runs every month against per-ticket extraction.

Rolling tickets up by job, and what happens after extraction

A monthly bill with 200 tickets routinely covers 5 to 15 jobs at a mid-sized GC. Aggregating at the header level forces an AP clerk to back into per-job allocation by reading every ticket page and tallying by hand; per-ticket extraction with a clean job/PO column does the allocation up front and lets a pivot do the rest.

The mechanics are simple once the rows are in place. The per-ticket spreadsheet pivots or filters by job/PO instantly, with quantities and dollar values rolling up per job. Those rollups feed WIP reporting and per-job cost posting. Mismatches between the job/PO the supplier printed on the ticket and the job the foreman expected — usually because the dispatcher coded the load to the wrong job at the plant — surface as outliers when the per-job aggregate looks too high or too low against the field copies. That's the kind of error that's invisible at the header level and obvious in a per-job rollup. For the AP-side mechanics of split one supplier invoice across multiple construction jobs, the parallel-pattern article walks the allocation step in more detail; for bulk-materials suppliers, the per-ticket job/PO column is what makes the split mechanical rather than judgmental.

Some bills mix jobs without per-ticket PO references. The dispatcher skipped the field, the scale operator didn't ask, or the truck went out on an emergency load before the PO was issued. The reconciliation against field copies fills the gap, but it's manual work — the clerk has to walk each blank job/PO row back to the foreman's field copy or to a delivery confirmation and assign the job by hand. A prompt that flags missing job/PO values for review is more useful than one that silently leaves the field blank or, worse, guesses based on adjacent rows; per-ticket extraction for construction job costing only works when the rows that need review are visible.

What happens after extraction lives downstream of the spreadsheet. The contractor's AP system consumes the per-ticket rows for posting, the job-cost system consumes them for WIP, and the GL coding decisions get applied at posting — the job-cost coding for construction supplier invoices article walks the coding logic for those line items in depth. The audit column with the source PDF page reference lets the AP reviewer spot-check any suspicious row against the original ticket image without leaving the spreadsheet. Extraction stops at the spreadsheet; everything past that is the workflow the contractor's existing systems already run.

---

Where Invoice Data Extraction fits, and where Vergo or Field Materials AI fit instead

Invoice Data Extraction is built around a single prompt field and a file upload area, the same interaction model anyone using ChatGPT or Claude already knows. For per-ticket extraction, that means the contractor writes a prompt naming the per-ticket columns they actually need — ticket number, ticket date, job/PO, supplier, plant, material code and description, quantity, unit, unit price, line total, plus whichever material-specific columns their suppliers print (net tons and haul distance for aggregate haulers, mix design and CY for ready-mix, load number and tons for asphalt) — uploads the month's supplier invoices, and downloads the per-ticket rows in Excel, CSV, or JSON. The prompt is the configuration; there are no per-supplier templates to build or rules engines to maintain.

The same simple interface holds for the volumes contractors actually process. Batches run up to 6,000 files per job, with single PDFs accepted up to 5,000 pages, which comfortably covers a month's run of supplier invoices across multiple suppliers or a single supplier's 400-page summary bill. The same prompt produces the same row schema across every document in the batch, which is the practical difference between a tool built for serious volume and a general-purpose AI tool that handles a handful of invoices well and falls apart at hundreds.

Prompts that work get saved. The prompt library lets a contractor keep a handful of per-supplier prompt variants — an aggregate-supplier prompt with the gross-tare-net columns and haul distance, a ready-mix prompt with mix design and CY and water-add fields, an asphalt prompt with load number and tons and mix code — and apply the right one to each supplier's monthly bill without rewriting the schema each time. Every output row carries a reference back to the source file and page number, so the audit column the spreadsheet schema relies on lands automatically. The use case here is a clean one for a tool designed to extract construction supplier invoices and attached tickets to a spreadsheet — the prompt does the per-ticket field mapping, the batch handles the page count, and the saved prompts make the recurring monthly run repeatable.

The boundary is worth stating explicitly. Invoice Data Extraction extracts per-ticket rows into a spreadsheet. It does not perform PO matching against an open-PO file. It does not post to the GL. It does not integrate directly with Sage 300 CRE, Foundation, ComputerEase, or Procore. The output is a spreadsheet the contractor's existing AP and job-cost systems consume on their own terms — by import, by re-key, by a script the team has already built. That boundary is the point of the workflow, not a caveat.

The closed alternatives are real and worth naming honestly. Vergo, Field Materials AI, Beiing Human, Kojo, and SubBase market closed construction-AP products that extract supplier-invoice data, match against purchase orders, route for approval, and post results into construction ERPs end to end. Contractors who want the full AP workflow inside one product — and who are committed to the construction ERP that product integrates with — will be better served by one of them. The trade-off is workflow ownership: the closed product owns the workflow end to end and gives the contractor a posted result, while the spreadsheet workflow gives the contractor the per-ticket rows to do whatever they want with downstream — hand off to an accountant, reconcile against foreman field copies, import into a job-cost system the AP product doesn't integrate with, pivot for monthly close in Excel. Contractors who want the spreadsheet stay in the prompt-based extraction lane; contractors who want the closed product self-select to Vergo or Field Materials AI.