Paddock Pro

How the stable gets paid: board contracts per box and horse, extra services logged at the moment they are done, prepaid credit, recurring invoices, SEPA direct debit, VAT treatment that a tax adviser accepts, and an export to the accountant.

0 — No billing at all; services are noted somewhere and invoiced by hand in another tool.

3 — A list of services or a price table per horse, but invoices are written outside the system and nothing connects a logged service to a charge.

5 — Board contracts and extra services billed from the system: monthly invoices generated from contracts plus logged services, sent to the boarder, with payment status tracked.

8 — Services logged on the phone where they happen flow into the invoice or a prepaid balance automatically, SEPA direct debit with mandates, VAT rates configurable per service type, cancellation and credit notes, and an export to DATEV or a named accounting tool.

10 — The money side is discharged inside the system: GoBD-compliant numbering and archiving stated, e-invoices (XRechnung/ZUGFeRD) supported, prepaid credit with low-balance warnings, dunning, multiple payers per horse (shares, Reitbeteiligung) split correctly, and every charge traceable to the logged service and the staff member who logged it.

The record per horse: master data and passport details, feeding and supplement plans, vaccinations, worming, farrier and vet appointments, medication given, turnout and blanket instructions — kept so that a vet, an inspector or the owner can rely on it, and exportable when the horse leaves.

0 — No horse records beyond a name; care instructions live on a whiteboard.

3 — A profile per horse with free-text notes and perhaps a photo, but no structured feeding plan, no health schedule and no history.

5 — Structured feeding plans per horse shown to staff by feeding round, vaccinations, worming and farrier dates recorded with reminders, and appointments per horse in a calendar.

8 — Health records with due dates to the FN/LPO vaccination schedule, a medication log with dose, date and who administered it, owner instructions (blankets, turnout, special feed) visible to whoever does the round, and a full history per horse exportable as a document.

10 — A record that stands up to scrutiny: medication documentation meeting the TAMG duties for food-producing equines stated, passport and UELN data held, every change attributed and dated, vet and farrier entries from external professionals possible, and the complete file handed to a new stable in a documented export format.

The daily running of the yard: tasks and feeding rounds, shift and holiday planning, time recording for employees and mini-jobbers, help from boarders (Stalldienst), and reminders — and, where staff are clocked in by location, how that is done and documented.

0 — No staff or task features; the day is organised by phone and paper.

3 — A shared to-do list or chat, with no assignment, no recurrence and no record of who did what.

5 — Recurring tasks and rounds assigned to people with completion ticked on the phone, a shift plan, and reminders for due work.

8 — Time recording for employees that meets the minimum-wage and working-time documentation duties, holiday and absence planning, boarder duty rotas for self-care stables, completion history per task, and any location-based clock-in documented as opt-in with its purpose stated.

10 — Operations run and are evidenced in the system: rotas, time records and absences exported to payroll, permissions per role (owner, manager, groom, boarder), offline use in a barn without signal, and an audit trail answering who fed, medicated or turned out which horse when.

What the horse owner sees and does: their horse's records and the services billed to them, instructions to the stable, bookings, news from the yard — and how their personal data and their horse's data are scoped, so each owner sees their own horse and nothing else.

0 — No owner access; everything goes by WhatsApp, phone or a notice board.

3 — A group chat or news feed for the whole yard, with no per-owner view of their own horse or bill.

5 — Owner login showing their own horse's released records, logged services and invoices, with a way to send instructions or requests to the stable.

8 — Owners, co-owners and Reitbeteiligungen scoped separately with the stable deciding what is released, push notifications for due dates and charges, bookings and requests with status, and the privacy policy naming how owner data is processed.

10 — The portal replaces the phone calls: every record and charge an owner is entitled to see available on demand, instructions acknowledged by the staff member who reads them, owner data exportable and deletable on request, and roles that keep one boarder's data out of another's view by design.

The yard's shared resources and teaching business: arena and indoor school bookings, horse walker, treadmill and solarium use, lessons and school horses, courses and clinics with registration and payment, guest boxes.

0 — No booking or lesson features.

3 — A shared calendar where anyone can type an entry, with no rules, no capacity and no link to billing.

5 — Arena and equipment booking with time slots and rules, lessons scheduled with riders and school horses, and courses with online registration.

8 — Bookings with capacity, closures and booking rules per user group, equipment use linked to billing or credit, lesson cards or subscriptions, school-horse workload tracked, and events with participant management and payment.

10 — The facility runs on the system: device integration (NFC, gates, walker or solarium controllers) recording use automatically, external riders and guests bookable with their own terms, lesson and course revenue flowing into the same accounts as board, and utilisation reported per facility.

Who the contracting entity and the parent company are, where boarder, staff and horse data are hosted, and who the subprocessors are (hosting, push notifications, payments, email). Independently sourced by the sovereignty pipeline; a phone app also sends data through the app-store and push providers, so the chain counts, not only the server.

0 — Non-EU vendor and contracting entity, hosting unstated, subprocessors unnamed, and no privacy policy that covers the app.

3 — A privacy policy exists, but hosting location is unstated or non-EU and the processors behind the app (analytics, push, payment) are not named.

5 — EU hosting stated and an EU contracting entity, but parts of the chain (push notifications, analytics, email, payment) run through non-EU providers without a stated safeguard.

8 — EU hosting on named infrastructure, EU contracting entity, subprocessors listed with locations, a data processing agreement offered to the stable for boarder and staff data, and location tracking of staff described with its legal basis.

10 — Sovereign end to end and evidenced: European ownership, entity, hosting and every subprocessor, data export and deletion documented, and a security or certification statement published rather than implied.

Whether a stable owner can compute the real annual cost from public pages alone: price per stable, box, horse or module, which modules (billing, staff, portal, devices) cost extra, setup fees, minimum term, and what happens to the data on cancellation.

0 — No public prices at all; every stable is a sales call.

3 — A starting price or "from" figure exists, but what is included and how it scales with horses or modules is unclear.

5 — Prices per tier or module are public with the main inclusions, but at least one commonly needed piece (billing, device integration, extra users, setup) is unpriced or "on request".

8 — Every tier and module priced publicly with its scaling rule (per box, horse or user), setup fees and add-ons listed, minimum term and VAT treatment stated.

10 — Complete price computability: annual cost derivable for a given yard size and module set, with every add-on, setup, hardware and support cost and the cancellation and data-return terms published.