The scheduled export: a snapshot of survivors, not a record of events
In short
A DMS nightly extract file is a scheduled dump of the rows that still existed in the dealership's system of record when the export job ran — delimited flat files, one per object, generated off the back of the accounting day-end. It carries current state and no history, so it cannot show you deletions, intermediate states, ordering, or who changed anything.
Key takeaways
- The export carries rows that still exist, never the events that produced them.
- It falls out of the accounting day-end, so its dates are posting dates, not event times.
- Bind the parser to header names. Column order is not contractual and moves without notice.
- Deletions appear only as absence, which looks identical to a truncated file.
- A store's business day can close hours before midnight, so 'yesterday' is not yesterday.
A scheduled dealership export is a set of flat files holding the rows that still existed in the store's system of record when the job ran. It is a photograph of the tables, not a recording of the day. Nearly everything a build can do with this data follows from that one property, and most integrations that go wrong on a nightly feed went wrong by reading it as a stream of changes.
It also exists for somebody else. The job runs behind the accounting day-end, when the ledger is internally consistent. You are the secondary consumer of an accounting artefact — which is why the dates are posting dates, and why nobody at the vendor treats a missing intermediate state as a defect.
What actually lands in the drop
The physical shape is unremarkable, and worth pinning down in writing before anyone designs on it. Every row below is somewhere a loader breaks quietly.
| Element | What you usually get | What varies | Consequence |
|---|---|---|---|
| Cadence | One drop per business day, overnight, onto SFTP or a bucket | Just after day-end to just before opening; weekends may produce nothing | Poll for it. Arrival time is not a schedule. |
| File set | One file per object: customers, vehicles, deals, order headers and lines, parts | A per-dealer entitlement, not a product feature | Two stores on one system get different sets. Confirm yours. |
| Delimiter | Comma, pipe or tab, occasionally fixed width | Whether values are quoted at all | One unquoted comma shifts every column to its right, on that row |
| Header row | Usually present, sometimes absent or repeated | Column order is not contractual and changes without notice | Bind to names. Positional parsing fails silently. |
| Encoding | CP1252 or UTF-8, CRLF or LF, sometimes mixed in one drop | Accented characters in names are what expose it | Detect per file. Last night's encoding is no guarantee. |
| Control record | A trailer row or sidecar file carrying a row count | Common enough to use, absent often enough that you cannot require it | Assert it when present; keep a range check when not |
Dates deserve their own line: posting or business dates, often date-only, in an undeclared store-local zone. Keep the raw string beside your parsed value. Provenance matters too — often a third party holding the dealer's authorisation produces the drop, so the columns are that party's reading of the source tables rather than the tables, which data brokers in the dealership stack takes apart.
Four things a snapshot structurally cannot tell you
- Deletions. A voided, merged or purged row simply stops appearing, and absence looks exactly like a short file — which is why it gets solved by reconciling what is missing, as the deal was voided and it is still open in your app works through.
- Intermediate states. An order that opened, split, was approved and closed between two runs appears once, closed. How long the approval sat does not survive, at any cadence.
- Ordering. Rows arrive in whatever order the query returned, with no sequence number, and the files are not generated at the same instant — so a deal can reference a customer absent from tonight's customer file.
- Who and why. The file carries the value, not the actor or the reason, so a figure that moved cannot be attributed to a person.
The business day is not the calendar day
'Nightly' hides two independent clocks. One is the accounting day-end, which decides which business day a transaction posts into. The other is the extract job, which decides when the file is written. Different people set them, and neither is published in the file.
What you can build on it, and what you cannot
- Build state, not history. A mirror of current records — inventory, open orders, contact details — is what a snapshot supports, and refreshing it wholesale each night is the honest implementation.
- Derive change, but call it derived. A row hash and a watermark make a full file behave like a change stream, which building a change stream from a full nightly file specifies.
- Promise nothing intraday. Availability, capacity and money go wrong fastest on stale data; which objects deserve a live read is settled per class in copy the data, or read it live.
- Keep every raw file, immutable, with a checksum. When yesterday's totals move, the only way to answer yesterday's export does not match today's copy is to still hold both files.
- Treat identifiers as local, not global — numbers are issued per store and reused across years, the argument in four times a repair-order number changes.
A snapshot transmits existence. It never transmits absence, and it never transmits the middle of anything.
Some records cannot be reconstructed from a snapshot at all. An ADAS calibration is the clean example: what matters afterwards is that a stated procedure ran on a given date under stated conditions, which is an event — recording a calibration so it holds up later sets out what it must carry.
Establishing what a store's export contains — objects, cadence, delimiter, day-end convention — is the first week of an integration, and it is the shape of scoping we run under MVP and product builds. The rest of this silo sits under DMS, CRM and shop-system integration, inside our automotive work.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is a DMS nightly extract file?
It is a scheduled dump of the rows that still exist in a dealership management system at the moment the job runs, delivered as delimited flat files, usually one per object. It falls out of the accounting day-end, which is why it carries current state and no change history.
What tables are usually in a dealership data export?
Most drops carry customers, vehicles, deals, repair-order headers and lines, parts and some accounting detail. The exact list is a per-dealer entitlement, so two stores on one system can receive different sets — confirm yours in writing before scoping.
Is a nightly file good enough, or do you need an interface that answers in real time?
A nightly file is enough for anything historical and wrong for anything that promises availability or moves money. Inventory display, reporting and service reminders survive a day of staleness; live scheduling and payment status do not.
Why do cancelled records keep appearing in a system built on a nightly export?
Because nothing in the file says they were cancelled — they simply stop appearing, and a loader that only upserts what it sees keeps the stale row forever. The fix is reconciliation by absence, guarded by a row-count check.
- dms integration
- data feeds
- flat files
- dealership data
The work behind this page
Builds from our portfolio that this page draws on.
Axlebound
Real-time fleet tracking and dispatching platform with full visibility over every vehicle, driver, and route.
LogisticsAskVault
An AI internal knowledge-search platform that answers employee questions from your own docs — grounded in citations, with knowledge gaps surfaced and deflection tracked.
Productivity AIRead next
- Data brokers in the dealership stack: who is actually sending you the fileBetween the dealership's system of record and your build sits a party with its own schema, its own cadence and an authorisation only the dealer can sign or revoke.definition
- Yesterday's export does not match today's copy of yesterdayA figure that was right on Tuesday is different on Wednesday. Four things cause that, three of them at the vendor and one in your loader, and the only thing that separates them is the raw files themselves.diagnostic
- The deal was voided in the DMS and it is still open in your appA voided deal or a deleted repair order never announces itself. It simply stops appearing in tonight's file, which looks identical to a truncated transfer — so the inference needs a health check before anyone trusts it.diagnostic
- Four times a repair-order number changes, and what to key on insteadAn RO number identifies a document at one store on one day. Four ordinary events renumber, duplicate or supersede it, and a fifth problem makes it repeat outright.definition
- The CRM says sixty-two, the DMS says fifty-eight, and the manager trusts neitherA 4-unit gap between two systems almost never means 4 lost records. Reconcile one month at record level into four buckets and the shape of the result names the cause before anyone has to argue about it.diagnostic
- The DMS and the CRM each believe they own the customerSample twenty customers who both bought and serviced, and count how many link on an identifier both systems actually store. The failure rate tells you whether this is drift or a missing design.diagnostic
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation