# BRD-039 — The sending-volume tier decides whether the sole-proprietor path is available

> A registration that requests a volume tier requiring a tax ID cannot be filed on the sole-proprietor path.

- **Rule ID:** BRD-039
- **Layer:** Brand (`BRAND`)
- **Checks:** `brand.entity_type + requested volume tier`
- **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright.
- **When it bites:** Gates approval — get this wrong and registration is refused
- **How it is detected:** Deterministic (settled in code from the submitted values)
- **Fix type:** Fix the field — a better value in the form clears it
- **Required by:** Textedly, Twilio
- **Applies:** Applies when the brand is a sole proprietor.
- **Canonical URL:** https://ekas.io/rules/10dlc/brand/brd-039/

## Why this rule exists

The sole-proprietor tier trades verification for throughput: it exists because an individual has no EIN, and it caps sending hard as a consequence. Choosing the tier and then requesting a volume it does not support produces a registration that is internally contradictory, and the platform resolves the contradiction by refusing the tier rather than by lowering the volume. Customers reach it by picking their plan first and their entity type second.

## How to fix it

Either drop to the volume the sole-proprietor tier supports — roughly 1,000 messages a day — or obtain an EIN and register as a standard brand at the volume you actually need. Done when the requested class and the entity type describe the same tier.

## Example of a compliant value

```text
entity_type: SOLE_PROPRIETOR with no brand class above it — or entity_type: PRIVATE_PROFIT with brand_class: STANDARD
```

## Common mistakes

- The cap is enforced by the CSP rather than by the carrier, so the traffic is not rejected message by message — it is throttled or the account is reviewed, which is harder to diagnose than a rejection.

## Provider rejection codes

| Provider | Code | Resubmission allowed |
| --- | --- | --- |
| Twilio | `30903` | yes |