Service Level Agreement

01Scope and incorporation

This Service Level Agreement (“SLA”) forms part of the Terms of Service between you and Nead, LLC (d/b/a DEV.co). Capitalised terms not defined here have the meaning given in the Terms.

This SLA applies to the production instance of the erp.io hosted software service for customers on a paid subscription and current in payment of undisputed amounts.

1.1 What is not covered

• Free trials, proof-of-concept environments, sandboxes, and Beta Services.
• Professional Services, which are governed by the applicable Statement of Work.
• The marketing website at erp.io, as distinct from the application.
• Third-Party Services, which are governed by their own providers’ terms.

Where an Order Form contains a bespoke service level, that document controls to the extent of any conflict.

02Availability commitment

We commit to 99.9% Monthly Uptime Percentage for the Covered Services.

99.9% permits approximately 43 minutes and 12 seconds of Downtime in a 30-day month. We state that plainly because a percentage is easy to quote and harder to translate, and if your operation cannot tolerate 43 minutes you should tell us during evaluation rather than after.

2.1 Covered Services

03How availability is measured

3.1 Definitions

Downtime means any period during which the Covered Services return an error, or fail to respond within 30 seconds, for a request that is valid, properly authenticated, and within applicable rate limits.

Monthly Uptime Percentage = (Total Minutes in Month − Downtime Minutes) ÷ Total Minutes in Month × 100.

3.2 Successful request handling, not ping

Availability is measured against successful handling of actual requests, not against whether a server responds to a health check. A system returning errors quickly is unavailable. Measuring it any other way produces a number that flatters the vendor and misleads the customer.

3.3 Partial degradation counts proportionally

Where a proportion of requests fail, Downtime is calculated proportionally. If 30% of requests failed for one hour, that is 18 minutes of Downtime, not zero and not sixty.

3.4 Measurement source

Downtime is measured from our server-side monitoring, aggregated per minute. Where your own monitoring disagrees materially with ours, send us the data and we will investigate. If we cannot reconcile the difference, we will resolve the discrepancy in your favour for the purposes of a credit claim.

3.5 Published record

Monthly uptime is published at /status, including months below target. A reliability figure you cannot check is marketing, and the value of the months we meet the target depends entirely on our publishing the ones we miss.

04Service credits

4.1 Credit schedule

“Monthly fee” means the subscription fee attributable to the affected month, calculated as one twelfth of an annual fee where billing is annual.

4.2 Termination right for sustained failure

If Monthly Uptime Percentage falls below 99.0% in any three months within a rolling twelve-month period, or below 95.0% in any single month, you may terminate the affected Services on 30 days’ written notice and receive a pro-rata refund of prepaid unused fees, in addition to any credits due.

4.3 How to claim

Email [email protected]with “SLA claim” in the subject line and the affected month. That is the whole process.

• Claims must be submitted within 60 days of the end of the affected month.
• You do not need to prove loss or damage. The credit is not compensation for damage; it is a price adjustment for a service level not met.
• You do not need to supply logs. If our records show the shortfall, we will apply the credit whether or not you provided evidence.
• We will respond within 10 business days confirming the calculation or explaining why we disagree, with our measurement data.

4.4 Proactive credits

Where our own monitoring shows we missed the commitment, we will apply the credit without waiting for a claim and tell you we have done so. A credit that depends on the customer noticing is a credit designed not to be paid.

4.5 Application of credits

Credits are applied against future invoices, or refunded if no further invoice will issue because the subscription is ending. Credits are not cash except in that case, and are not transferable.

4.6 Exclusive remedy

Service credits are your sole and exclusive remedy for failure to meet the availability commitment, except that this does not limit your termination right under Section 4.2 or any claim arising from a breach that also constitutes a material breach of the Terms.

05Exclusions

Downtime does notinclude unavailability caused by the following. This list is exhaustive — we have not included a general catch-all, because an exclusions list ending in “or any other cause outside our reasonable control” can swallow the entire commitment.

• Scheduled maintenance announced at least 72 hours in advance, capped at 4 hours per month and performed outside 07:00–19:00 United States Central Time on business days.
• Emergency maintenance necessary to preserve security or data integrity, capped at 2 hours per month for exclusion purposes. Beyond that cap, it counts as Downtime.
• Your acts or omissions, including misconfiguration, exceeding documented rate limits, invalid credentials, or use in breach of the Acceptable Use Policy.
• Third-Party Service failures — a bank feed, accounting API, payroll provider, or similar being unavailable. Our own connector infrastructure is not excluded.
• Your network or equipment, including your internet connectivity, firewall, VPN, DNS resolution, or identity provider.
• Suspension properly exercised under the Terms for non-payment or acceptable-use breach.
• Force majeure as defined in the Terms, provided we notify you and take reasonable steps to mitigate.
• Beta Services, trials, sandboxes, and proof-of-concept environments.

06Maintenance

6.1 Scheduled maintenance

• Announced at least 72 hours in advance by email to the account contact and on the status page.
• Performed outside 07:00–19:00 United States Central Time on business days where practicable.
• Capped at 4 hours per calendar month for exclusion purposes. Time beyond that counts as Downtime.
• Most deployments require no downtime at all. Scheduled maintenance windows are the exception rather than a routine occurrence.

6.2 Emergency maintenance

Performed without advance notice where necessary to preserve security, integrity, or availability. We will notify you as soon as practicable, and publish a written explanation afterwards. Capped at 2 hours per month for exclusion purposes.

6.3 Avoiding period-end

We avoid scheduled maintenance during the first five and last three business days of a calendar month, which is when most customers are closing. Where a security requirement makes that impossible, we will say so explicitly in the notice.

07Degradation ordering under partial failure

Under resource constraint or partial failure, the Services shed capability in a fixed order. This is design rather than accident, and it is stated here so you can plan against it.

Agent pausing is not Downtime under this SLA, because it is the system behaving as designed to protect the ledger. We still record it as a partial incident on the status page, because if automation you were relying on stopped, you should be able to see that it stopped and why.

08Recovery objectives and data durability

RPO and RTO are objectives rather than guarantees, and failure to meet them in a disaster scenario does not itself trigger credits beyond those arising from the resulting Downtime. We state them because a customer running their finance function on our software is entitled to know the worst case.

8.1 Independent protection

Regardless of our recovery capability, you can and should maintain your own copy. Scheduled export to storage you control is a standard capability, runs while everything is fine, and is the protection that does not depend on us continuing to exist.

09Support response targets

Support targets are commitments to respond, not to resolve. Resolution time depends on the issue and we will not promise a number we cannot control.

Business hours are 09:00–18:00 United States Central Time, Monday to Friday, excluding United States federal holidays. Critical issues are handled outside those hours by whoever is on call.

9.1 No paid priority

Response targets are identical for every customer regardless of plan size. We do not sell priority support and we do not place a smaller customer behind a larger one. Enterprise plans add named contacts and the credits in this SLA, which is a commitment mechanism rather than a faster queue.

9.2 Escalation

If a response is slow or an answer unsatisfactory, email [email protected]with “Escalation” in the subject line. There is no tier structure to navigate; escalation means a different person reads it the same day.

10Incident communication

• Status page. Updated within 30 minutes of confirming a customer-affecting incident, and at least hourly until resolved.
• Direct notification. Customers whose tenant is affected are contacted directly rather than left to discover the status page.
• Post-mortem. Published within 5 business days for any incident causing more than 30 minutes of Downtime, describing cause and remedy rather than noting elevated error rates.
• Data-affecting errors. Where an incident produced incorrect financial data, our error policy applies, including notification within 24 hours of confirmation and an impact assessment with affected records listed rather than characterised.

We record partial incidents — including Agent pauses that are intended behaviour — even where they are excluded from the availability calculation.

11Changes to this SLA

We may update this SLA. We will not reduce the availability commitment, reduce credit percentages, or broaden the exclusions during a paid term. Changes that improve the commitment take effect immediately.

For any change that is adverse to you, we will give at least 60 days’ notice and it will apply from your next renewal. If you do not accept it, you may elect not to renew.

Prior versions are available on request. Changes are logged in the changelog.