# `Stripe.Resources.Account.FutureRequirements`
[🔗](https://github.com/jeffhuen/tiger_stripe/blob/main/lib/stripe/resources/account.ex#L714)

Nested struct within the parent resource.

# `t`

```elixir
@type t() :: %Stripe.Resources.Account.FutureRequirements{
  alternatives:
    [Stripe.Resources.Account.FutureRequirements.Alternatives.t()] | nil,
  current_deadline: integer() | nil,
  currently_due: [String.t()] | nil,
  disabled_reason: String.t() | nil,
  errors: [Stripe.Resources.Account.FutureRequirements.Errors.t()] | nil,
  eventually_due: [String.t()] | nil,
  past_due: [String.t()] | nil,
  pending_verification: [String.t()] | nil
}
```

* `alternatives` - Fields that are due and can be resolved by providing the corresponding alternative fields instead. Many alternatives can list the same `original_fields_due`, and any of these alternatives can serve as a pathway for attempting to resolve the fields again. Re-providing `original_fields_due` also serves as a pathway for attempting to resolve the fields again. Nullable.
* `current_deadline` - Date on which `future_requirements` becomes the main `requirements` hash and `future_requirements` becomes empty. After the transition, `currently_due` requirements may immediately become `past_due`, but the account may also be given a grace period depending on its enablement state prior to transitioning. Format: Unix timestamp. Nullable.
* `currently_due` - Fields that need to be resolved to keep the account enabled. If not resolved by `future_requirements[current_deadline]`, these fields will transition to the main `requirements` hash. Nullable.
* `disabled_reason` - This is typed as an enum for consistency with `requirements.disabled_reason`. Possible values: `action_required.requested_capabilities`, `listed`, `other`, `platform_paused`, `rejected.fraud`, `rejected.incomplete_verification`, `rejected.listed`, `rejected.other`, `rejected.platform_fraud`, `rejected.platform_other`, `rejected.platform_terms_of_service`, `rejected.terms_of_service`, `requirements.past_due`, `requirements.pending_verification`, `under_review`. Nullable.
* `errors` - Details about validation and verification failures for `due` requirements that must be resolved. Nullable.
* `eventually_due` - Fields you must collect when all thresholds are reached. As they become required, they appear in `currently_due` as well. Nullable.
* `past_due` - Fields that haven't been resolved by `requirements.current_deadline`. These fields need to be resolved to enable the capability on the account. `future_requirements.past_due` is a subset of `requirements.past_due`. Nullable.
* `pending_verification` - Fields that are being reviewed, or might become required depending on the results of a review. If the review fails, these fields can move to `eventually_due`, `currently_due`, `past_due` or `alternatives`. Fields might appear in `eventually_due`, `currently_due`, `past_due` or `alternatives` and in `pending_verification` if one verification fails but another is still pending. Nullable.

---

*Consult [api-reference.md](api-reference.md) for complete listing*
