Automating 30%-Ruling Packet Prep: What's Possible and What Isn't
What the 30%-ruling packet prep process actually contains
A 30%-ruling application requires your firm to collect, verify, and assemble documentation across several categories:
- Identity and residency documents: passport, BSN (once issued), proof of prior address abroad
- Employment contract data: gross salary, start date, role description, country of prior employment
- Eligibility criteria checks: specific knowledge requirement, 150km rule verification, prior NL residency exclusion check
- Supporting documentation: diploma or equivalent for specific-knowledge cases, employer declaration
- Application assembly: structured packet submitted via the Belastingdienst portal or postal route
In a typical engagement, this process involves multiple back-and-forth exchanges with the assignee and their employer, a checklist review, and final assembly before the advisor reviews and submits.
The structured parts of this process are automatable: document completeness checking, field extraction, eligibility screening against defined criteria. The judgment parts, such as advising on edge cases, signing off on the application, and managing any dispute, are not.
The automation boundary in practice
Automatable (AI operates, advisor reviews output):
- Completeness check. Given a defined document checklist, an AI system can check whether each required item has been received and flag what's missing. No judgment is required, since this is a list comparison.
- Field extraction. From a submitted employment contract (PDF or structured form), extract: gross annual salary, start date, job title, country of previous employment. Flag if salary falls below the applicable threshold for the current year.
- 150km rule check. Cross-reference declared prior residential address against a defined radius from the Dutch border. Flag cases that are on the line for advisor review.
- Draft packet summary. Given complete, extracted data, draft the structured summary the advisor uses to complete the application. The advisor reviews and corrects before submission.
- Client status update. From intake form and submission data, draft a plain-language status email the advisor reviews and sends.
Not automatable (advisor judgment required):
- Interpreting edge cases (the assignee who moved to Germany 6 months before a Dutch contract, the employer who wants to argue the 150km rule)
- Deciding whether the specific-knowledge test is met in ambiguous cases
- Any advice that constitutes legal or tax counsel
- Signing off on submissions
What an Orellis implementation looks like
We are set up to build this as a working system for expat tax firms, not as a recommendation. The implementation follows our standard methodology:
- Map your current workflow. We document every step in your current intake process: who does it, what tools they use, where errors and delays occur.
- Identify the automation boundary. We agree with your team on which steps the AI handles and which the advisor reviews. This boundary is documented.
- Build and deploy. We build the system during the engagement. Your named operator (an advisor or office manager) can run it solo by the end of week one.
- Document the human-in-the-loop protocol. For every AI-generated output, there is a defined review step before it reaches a client or a submission. We document this for your EU AI Act self-assessment.
The system runs on infrastructure designed for EU data residency. Every AI-generated output carries a disclosure. You own the runbook.
One question before we scope anything.
How many active 30%-ruling cases does your firm handle at any given time? That single number determines whether the build cost is justified. Send it to rachel@orellis.ai.