What columns belong in a simple towing reporting CSV?

Establish what the records mean

The lab’s supported combined file uses type, id, inquiry_id, job_id, at, status, suitable, amount, direct_cost and source. Every row has a type and its own ID. Event and job rows can reference an inquiry; payment rows can reference a job. Dates use YYYY-MM-DD in this demonstration, so it does not perform time-of-day analysis.

A worked example

Fictional chain: event E1 links to inquiry I1; job J1 links to I1; payments P1 and P2 link to J1. Two payments do not create two jobs. A blank inquiry link remains unresolved, and a blank direct_cost remains unknown. The sample download includes retries, a transfer, a cancellation, refunds and payments in a later month.

Choose the next action

Map each supported column explicitly when importing. Use plain decimal money with no currency symbols or thousands separators, and keep negative payment values for documented adjustments. Use yes, no or unknown for inquiry suitability and the supported job statuses. Do not include names, phone numbers, addresses or card information in this teaching file.

Check whether it worked

Validate IDs, dates, row widths and references before trusting totals. Preserve the original file and dictionary version. Compare imported row counts and inspect unresolved records in the lab. Provider-specific exports need their own verified field mapping; this schema does not imply a working Towbook, Autura or payment-platform integration.

A repeatable review order

1. Column name and meaning. Record the evidence and mark any missing answer as unknown.
2. Record type and unique ID. Record the evidence and mark any missing answer as unknown.
3. Explicit reference fields. Record the evidence and mark any missing answer as unknown.
4. Allowed values and blank meaning. Record the evidence and mark any missing answer as unknown.
5. Mapping, validation and version. Record the evidence and mark any missing answer as unknown.