Extract data from SLAs

A service level agreement fixes the promises a vendor makes about how well a service will run, and the money that changes hands when those promises are missed. It sits beside a Master Services Agreement rather than replacing it: where an MSA sets the parties, the liability regime, and the intellectual property terms, and a statement of work sets the deliverables and their prices, an SLA sets measurable targets, availability, response time, and resolution time, and the service credits owed when a target is not met. The people who live in it are the vendor operations lead who reports against it every month, the customer procurement team that negotiated the credits, and the incident manager who reaches for it the moment an outage starts. Precision lives in the numbers and the window they are measured over. A hosting SLA might guarantee 99.9% monthly availability, which allows roughly 43 minutes of downtime in a 30 day month, a 30 minute response target for a Priority 1 incident, and a 4 hour resolution target, each measured on a calendar month. When availability falls into a band, a service credit is owed: 10% of the monthly fee between 99.0% and 99.9%, 25% between 95.0% and 99.0%, and 50% below 95.0%, with the credits capped so the aggregate liability for a month cannot exceed 50% of that month's fee. Exclusions decide what does not count against the target, scheduled maintenance windows, force majeure, and downtime caused by the customer's own configuration, so the same outage can breach one SLA and not another. Talonic reads the SLA and returns the provider and recipient, the effective and expiration dates, the availability and time targets, and the penalty structure as fields, keeping the service levels, the penalties, and the exclusions as tables. Point it at a cloud hosting SLA dated 2026-07-01 between Halcyon Cloud Services GmbH as provider and Meridian Retail AG as recipient, guaranteeing 99.9% availability on a monthly window against a 40,000 EUR monthly fee, and the targets, the credit bands, and the 20,000 EUR liability cap load into a vendor management system as fields rather than clauses. Captured as written, the terms carry no judgment on whether a credit is owed or whether the agreement is enforceable.

What gets extracted from SLAs

How extraction works for SLAs

SLAs arrive as a schedule to an MSA, a standalone signed PDF, or a vendor portal export, and the targets and credits sit in tables whose columns shift from one provider to the next. Talonic classifies the document and aligns it to the contract schema kept in the Field Registry, whose clause set follows the CUAD taxonomy, so the availability target, the response and resolution times, the measurement period, and the penalty terms each resolve to their own field. The service levels return as a table of metric type, target value, unit, and measurement period, the penalties as a table of breach threshold, credit type, amount, and the maximum liability per period, and the exclusions as their own table so scheduled maintenance and force majeure are legible rather than buried. Uptime target is typed as a number and the service credit bands are checked against the monthly fee, so a 10% credit on a 40,000 EUR fee is verified to be 4,000 EUR rather than trusted. Every value carries a confidence score and a pointer to its source region in conformance with DIN SPEC 91491, so a procurement or operations reader can trace a credit band back to the clause it came from. Returned as written, the commitments leave the question of whether a breach occurred to the parties.

Sample extraction

A managed cloud hosting SLA scheduled to an MSA

{
  "document_number": "SLA-2026-0417",
  "document_date": "2026-06-24",
  "effective_date": "2026-07-01",
  "expiration_date": "2027-06-30",
  "service_provider.name": "Halcyon Cloud Services GmbH",
  "service_recipient.name": "Meridian Retail AG",
  "service_description": "Managed cloud hosting and 24x7 incident support for the Meridian ecommerce platform",
  "uptime_percentage": 99.9,
  "response_time": "30 minutes for Priority 1 incidents",
  "resolution_time": "4 hours for Priority 1 incidents",
  "measurement_period": "Calendar month",
  "penalty_type": "service_credit",
  "penalty_amount": 4000,
  "penalty_currency": "EUR",
  "cap_on_liability": "50% of the monthly service fee, being 20,000 EUR",
  "governing_law": "Federal Republic of Germany",
  "escalation_contact": "noc@halcyoncloud.example, +49 30 5550 1180",
  "renewal_term": "Auto-renews for successive 12 month terms unless 60 days notice is given",
  "service_levels": [
    {
      "metric_type": "Availability",
      "metric_value": "99.9",
      "measurement_unit": "percent",
      "measurement_period": "Monthly"
    },
    {
      "metric_type": "Response time (P1)",
      "metric_value": "30",
      "measurement_unit": "minutes",
      "measurement_period": "Per incident"
    },
    {
      "metric_type": "Resolution time (P1)",
      "metric_value": "4",
      "measurement_unit": "hours",
      "measurement_period": "Per incident"
    }
  ],
  "penalties": [
    {
      "breach_threshold": "Availability 99.0% to 99.9%",
      "penalty_type": "service_credit",
      "penalty_amount": 4000,
      "penalty_currency": "EUR",
      "maximum_liability": "20,000 EUR per month"
    },
    {
      "breach_threshold": "Availability 95.0% to 99.0%",
      "penalty_type": "service_credit",
      "penalty_amount": 10000,
      "penalty_currency": "EUR",
      "maximum_liability": "20,000 EUR per month"
    },
    {
      "breach_threshold": "Availability below 95.0%",
      "penalty_type": "service_credit",
      "penalty_amount": 20000,
      "penalty_currency": "EUR",
      "maximum_liability": "20,000 EUR per month"
    }
  ],
  "exclusions": [
    {
      "exclusion_type": "Scheduled maintenance",
      "exclusion_description": "Downtime during the announced Sunday 02:00 to 06:00 CET maintenance window"
    },
    {
      "exclusion_type": "Force majeure",
      "exclusion_description": "Events beyond the reasonable control of the provider"
    },
    {
      "exclusion_type": "Customer-caused",
      "exclusion_description": "Downtime resulting from customer configuration changes or third-party integrations"
    }
  ]
}

Frequently asked