SLAs for vendor CSV files: what to specify beyond "valid CSV"

A lot of vendor file agreements fail because they stop at the wrong sentence.

They say things like:

• “Vendor will provide a valid CSV file”
• “CSV will be delivered daily”
• “Headers will follow agreed format”
• “Files must be importable”

That sounds reasonable until the first production incident.

Then you discover the file was:

• technically valid CSV
• but delivered eight hours late
• missing a critical column
• full of duplicate rows
• still comma-delimited but with renamed headers
• structurally fine yet 40% null in fields that matter
• or quietly changed in a way your pipeline could parse but not trust

That is the central problem with weak CSV SLAs:

they define syntax without defining reliability.

This guide explains what to specify beyond “valid CSV” so the agreement protects the actual downstream workflow, not just the parser.

Why this topic matters

Teams usually search for this after one of these issues:

• vendor changed column names with no notice
• file arrived late and broke daily reporting
• row counts dropped unexpectedly
• duplicates spiked without explanation
• UTF-8 or delimiter rules were technically correct but business data was unusable
• SLA said “daily file” but never defined a cutoff time
• file passed structural validation but failed every meaningful business check
• nobody knew whether to quarantine, accept, or escalate

That means the real search intent is broader than “CSV syntax.” It is about:

• data contracts
• delivery guarantees
• quality thresholds
• schema governance
• support responsibility
• and operational accountability

That is why the best version of this page is not about CSV parsing alone. It is about what makes a vendor-delivered CSV operationally trustworthy.

Start with the key distinction: format compliance vs delivery reliability

RFC 4180 gives useful baseline rules for common CSV structure:

• records are line-based
• fields are comma-separated
• optional headers may exist
• fields containing commas, quotes, or line breaks require quoting
• embedded quotes must be escaped by doubling them

That is important because it defines a structural floor.

But RFC 4180 does not tell you:

• whether the file is on time
• whether the headers are still the ones you expect
• whether nulls are acceptable in specific columns
• whether row counts are plausible
• whether duplicate records are allowed
• whether the file is fresh enough for your daily process
• whether the vendor had to notify you before changing anything

That is why “valid CSV” is not an SLA. It is only one clause inside one.

The first thing to specify: delivery timing with real cutoffs

“Daily file” is not specific enough.

A practical SLA should define:

• expected cadence, such as daily, hourly, weekly
• the time zone
• the latest acceptable delivery time
• what counts as late
• what happens if the file misses the deadline
• whether partial deliveries are allowed
• whether weekends and holidays change the expectation

This is one of the most common gaps in vendor file contracts.

A stronger version looks like:

• daily by 06:00 UTC
• warning threshold at 06:15 UTC
• breach threshold at 07:00 UTC
• rerun or re-delivery required within 60 minutes of confirmed vendor-side failure

This is also where dbt’s source freshness docs are a useful mental model. dbt explicitly supports warn_after and error_after thresholds for source freshness, which is exactly the kind of operational specificity vendor SLAs should borrow:

• warning threshold
• failure threshold
• explicit clock

That is much better than “fresh daily data.”

The second thing to specify: file freshness, not just file arrival

A file can arrive on time and still be stale.

For example:

• the delivery is at 06:00 UTC
• but the most recent data inside the file is from two days ago
• or the file was resent accidentally from an old batch

That is why the SLA should specify freshness separately from delivery.

Typical freshness clauses include:

• maximum data age
• expected loaded-at timestamp or extraction timestamp
• whether the file must represent a full daily snapshot or incremental change set
• how late-arriving source records are handled
• whether reruns replace or append prior deliveries

Useful language might define:

• acceptable age of newest record
• acceptable lag from source extraction
• required batch timestamp field
• how to identify a rerun versus a fresh file

Without that, teams often meet the delivery SLA while still failing the business need.

The third thing to specify: schema stability and change notice

This is one of the highest-value SLA sections because silent schema drift is so common.

A strong CSV SLA should specify:

• expected header names
• required columns
• optional columns
• column order if relevant
• delimiter
• quote rules
• encoding
• whether new columns may be appended
• whether removed columns require approval
• required notice period for schema changes
• versioning expectations

dbt’s model contracts docs are useful here as a conceptual anchor. They frame a contract as the defined shape of the returned dataset. That same mindset applies to vendor CSVs: if the shape changes unexpectedly, that is a breaking change.

A real SLA should treat:

• renamed columns
• removed columns
• changed semantic meanings
• new nullability behavior
• changed type-like behavior as contract changes, not “minor vendor updates.”

The fourth thing to specify: structural requirements beyond “CSV”

Even though this article is about what goes beyond valid CSV, you still need to specify the structural baseline clearly.

At minimum:

• delimiter
• quote handling expectations
• header presence
• encoding
• line ending tolerance if relevant
• whether trailing blank lines are acceptable
• whether duplicate headers are forbidden
• whether files may contain embedded newlines inside quoted fields

RFC 4180 helps define the common baseline here, including that fields containing commas, quotes, or line breaks should be quoted and that embedded quotes should be doubled.

This matters because “CSV” in the wild can still mean:

• semicolon-delimited exports
• inconsistent quoting
• UTF-8 in one week and another encoding the next
• or spreadsheet-edited files that open fine but do not meet parser expectations

A vendor SLA should remove that ambiguity.

The fifth thing to specify: row-count and completeness expectations

A file can be structurally valid and still obviously wrong because it is too small, too large, or missing a logical segment.

That is why strong SLAs often define:

• minimum expected row count or row-count tolerance bands
• expected presence of mandatory partitions or groups
• completeness thresholds for required entities
• whether a zero-row file is allowed and under what conditions
• whether an empty file must still include headers
• whether summary or manifest counts are required

This is where simple observability becomes powerful.

For example, requiring:

• batch row count
• source system extract count
• file size
• checksum
• extraction timestamp

gives you early signals when something drifted even before semantic checks run.

The sixth thing to specify: duplicates and uniqueness tolerance

A lot of vendor SLAs forget duplicates entirely.

That is a mistake because duplicate tolerance is often a business decision, not just a technical one.

You should define:

• which key or key combination is expected to be unique
• whether duplicates are forbidden, tolerated, or quarantined
• acceptable duplicate rate if any
• how corrections or reruns should be identified so they do not look like duplicates
• whether full snapshots may repeat prior records intentionally

This matters because the same file can be:

• acceptable for append-only processing
• unacceptable for point-in-time reporting
• or dangerous for idempotent loads

If uniqueness is important, the SLA should say so explicitly.

The seventh thing to specify: null, blank, and default-value expectations

Null handling is one of the most under-specified parts of vendor CSV agreements.

A good SLA should answer:

• which columns are required
• which columns may be blank
• whether blank and null are treated differently
• what placeholder values like N/A, NULL, or empty string mean
• whether missing values can exceed a threshold
• whether specific fields have completeness targets

This maps directly to common data-quality dimensions such as completeness and validity. Google Cloud’s data governance overview highlights accuracy, completeness, consistency, timeliness, validity, and uniqueness as core data-quality dimensions. Those categories are a good lens for SLA design because they push the agreement beyond “the file exists.”

For CSV SLAs, completeness is especially important.

The eighth thing to specify: data quality thresholds and error budgets

This is where SLAs become operational instead of aspirational.

A strong vendor CSV SLA should define measurable thresholds such as:

• maximum duplicate rate
• maximum null rate in required fields
• maximum malformed-row count
• maximum late-file frequency
• acceptable percentage of rows passing format checks
• acceptable percentage of rows passing business checks
• whether failures create warnings or hard breaches

Google Cloud’s auto data quality docs are useful here because they explicitly distinguish row-level rules from aggregate rules, and they support thresholds for passing rows versus aggregate conditions. That is a very practical model for vendor CSV SLAs:

• row-level checks for per-row conformance
• aggregate checks for file-level health
• thresholds that define failure

This is also where error budgets fit well:

• not “perfect data always” but
• “acceptable failure rate defined in advance”

The ninth thing to specify: support, escalation, and remediation

A vendor CSV SLA is incomplete if it defines the problem but not the response.

You should define:

• who is the named vendor owner
• who is the named consumer owner
• support hours and time zone
• incident severity classes
• acknowledgement time
• workaround time
• re-delivery expectations
• correction expectations
• whether bad files are resent with the same name or a new version
• whether the vendor must provide root-cause analysis for repeated failures

This matters because many teams have excellent validation and terrible escalation.

The parser tells you the file is wrong. Nobody knows who must fix it or by when.

That is not a complete SLA.

The tenth thing to specify: versioning and backward compatibility

Not every vendor can freeze a CSV forever.

But if the shape can change, the contract should say how.

Useful rules include:

• schema versions in the filename or manifest
• breaking changes require a minimum notice period
• non-breaking additions allowed only in append-safe ways
• overlapping support window for old and new versions
• test files provided before cutover
• cutover date and rollback date defined in writing

This is one of the strongest ways to reduce surprise incidents.

The eleventh thing to specify: file naming, manifests, and lineage

Operationally mature SLAs often define:

• file naming convention
• expected path or bucket location
• required timestamps in names
• whether sequence numbers are required
• manifest or companion metadata file
• checksum requirement
• whether reruns keep or replace the original name
• whether the same logical batch can appear twice

This is not just housekeeping. It supports:

• replay
• reconciliation
• support debugging
• auditability
• and safer automation

A file with the right rows but no reliable batch identity is still hard to run professionally.

The twelfth thing to specify: acceptance, quarantine, and rollback behavior

A vendor SLA should say what happens when the file misses the contract.

Possible states:

• accept fully
• accept with warnings
• quarantine file
• quarantine rows
• reject file
• ingest but mark as degraded
• require vendor re-delivery
• revert to last-known-good dataset
• disable downstream publish

Those choices should not be invented in the middle of an incident.

A good SLA names them beforehand.

A practical SLA template outline

If you want a usable structure, include these sections:

1. Delivery contract

• cadence
• time zone
• cutoff
• lateness thresholds

2. Freshness contract

• extraction timestamp requirement
• max data age
• snapshot vs incremental semantics

3. File structure contract

• delimiter
• encoding
• header presence
• quote handling
• line-ending expectations

4. Schema contract

• required columns
• optional columns
• breaking-change rules
• versioning and notice period

5. Data quality contract

• completeness targets
• uniqueness rules
• validity rules
• row-count tolerances
• malformed-row tolerance
• null budgets

6. Operational contract

• file naming
• delivery location
• manifests/checksums
• retry and re-delivery rules

7. Incident and escalation contract

• named owners
• support windows
• acknowledgement and remediation times
• RCA expectations

That is much closer to a real SLA than “must be valid CSV.”

Common anti-patterns

Anti-pattern 1. “Delivered daily” with no cutoff time

This creates arguments instead of observability.

Anti-pattern 2. Defining syntax but not freshness

You receive a parsable file that is useless.

Anti-pattern 3. Forgetting schema-change notice

The vendor changes headers and everyone acts surprised.

Anti-pattern 4. No duplicate or null thresholds

Data is “technically delivered” but not actually usable.

Anti-pattern 5. No rerun semantics

A correction file shows up and nobody knows whether to replace, append, or ignore it.

Anti-pattern 6. No named escalation owner

Validation fires, but nobody owns the breach.

Anti-pattern 7. No raw-file lineage

Support cannot reconcile which exact batch failed.

Which Elysiate tools fit this topic naturally?

The most natural companion tools for this page are the structural CSV validators, because a strong SLA still needs a mechanical way to test structural compliance:

• CSV Validator
• CSV Format Checker
• CSV Delimiter Checker
• CSV Header Checker
• CSV Row Checker
• Malformed CSV Checker

These fit naturally because they help enforce the structural floor, while the SLA defines the operational ceiling.

Why this page can rank broadly

To support broad search coverage, this page is intentionally shaped around several connected search clusters:

Core contract intent

• vendor csv sla
• csv data contract vendor
• supplier file delivery requirements

Data quality intent

• freshness sla for csv files
• row count tolerance vendor feed
• duplicate thresholds in data sla
• null budget csv contract

Operations intent

• schema change notice vendor file
• vendor file escalation process
• rerun semantics csv delivery
• acceptance criteria for vendor csv files

That breadth helps one page rank for much more than the literal title.

FAQ

Is “valid CSV” enough for a vendor SLA?

No. It only defines syntax. A useful SLA also defines freshness, delivery timing, schema stability, quality thresholds, change notice, and support behavior.

What is the most commonly missed requirement?

Schema-change notice is one of the biggest omissions. Many teams define headers once, but forget to require advance notice for renamed, added, removed, or semantically changed fields.

Should a vendor CSV SLA include data quality thresholds?

Yes. Strong SLAs define measurable thresholds for duplicates, missing values, freshness, row counts, and row-level or aggregate validation results.

How should freshness be specified?

Use explicit timing thresholds such as warn and fail windows, a known time zone, and a defined extraction timestamp or freshness field. Avoid vague language like “daily delivery.”

What should happen when a file breaches the SLA?

The contract should specify acceptance, quarantine, rejection, rerun, escalation, and remediation behavior in advance.

What is the safest default mindset?

Treat vendor CSV delivery as a real data contract: define syntax, timing, freshness, schema stability, data quality, and operational response in measurable terms.

Final takeaway

“Valid CSV” is necessary. It is not enough.

A vendor CSV SLA becomes useful only when it defines:

• when the file arrives
• how fresh the data must be
• what the schema is allowed to do
• what quality thresholds apply
• how failures are handled
• and who is responsible when the contract is breached

That is how you move from parser compatibility to operational reliability.