> ## Documentation Index
> Fetch the complete documentation index at: https://docs.symmetry.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Time periods (CTD, MTD, QTD, YTD)

> The input-vs-output convention for period-to-date amounts, and why it matters.

The STE tracks four time horizons for wages and withholding.

| Abbrev  | Meaning                                       |
| ------- | --------------------------------------------- |
| **CTD** | Current-to-date — the current pay period only |
| **MTD** | Month-to-date                                 |
| **QTD** | Quarter-to-date                               |
| **YTD** | Year-to-date (January 1 → now)                |

## What each surface calls them

The four horizons are the same concept on both surfaces, but only the on-premise SDK names the current period "CTD."

| Horizon         | Hosted API                         | On-premise SDK                          |
| --------------- | ---------------------------------- | --------------------------------------- |
| Current period  | `grossWages` on each `wages` entry | the `ctd` argument to `ste_set_wages()` |
| Month-to-date   | `mtdWages`                         | `mtd`                                   |
| Quarter-to-date | `qtdWages`                         | `qtd`                                   |
| Year-to-date    | `ytdWages`                         | `ytd`                                   |

<Note>
  The hosted API has no `ctdWages` field. Current-period wages are just `grossWages`, and the CTD label reappears only on the output side.
</Note>

Prior *withholding* is passed separately from wages, per tax. On the hosted API those are `periodWH`, `mtdWH`, `qtdWH`, and `ytdWH` on each `taxJurisdictionParms` entry.

## The critical convention: inputs exclude the current period, outputs include it

<Warning>
  **Inputs you provide are *prior* period-to-date figures — they exclude the current check.** The results the engine returns are *inclusive* — they include the current check. Mixing these up double-counts the current period.
</Warning>

| Direction                      | Current period                         | MTD / QTD / YTD                            |
| ------------------------------ | -------------------------------------- | ------------------------------------------ |
| **Input** (what you pass in)   | Current period wages                   | Prior periods **only** (before this check) |
| **Output** (what you get back) | This period's subject and excess wages | Cumulative **including** this check        |

Concretely: to calculate the third biweekly check of the year, you pass the current check's wages as the current-period figure — `grossWages` on the hosted API, `ctd` in the SDK — and the sum of the **first two** checks as YTD. The engine adds them internally and returns a YTD figure that now includes all three. A \$3,000 check with `ytdWages` of \$6,000 returns `"subjectWagesYTD": 9000` on Social Security.

Which of these figures a given tax reports is a separate question, covered next.

## Which period-to-date figures come back

The period-to-date fields on a result are there to show how far an employee has progressed toward a tax's limit. They are limit-tracking figures rather than general wage totals, so the engine fills in only the ones a given tax needs.

| Result fields                                                            | Returned for                                                                                                        |
| ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- |
| `subjectWagesCTD`, `excessWagesCTD`, `subjectWagesYTD`, `excessWagesYTD` | Taxes that have a wage base, plus Medicare (`MEDI`, `MEDI2`, `ER_MEDI`), which reports them even though it has none |
| `subjectWagesQTD`, `excessWagesQTD`                                      | Unemployment taxes only, where quarterly totals feed state UI reporting                                             |
| Any month-to-date figure                                                 | Never returned, though you can still supply `mtdWages`                                                              |

Federal income tax has no wage base, so it returns `0` for all six. Social Security returns current-period and year-to-date figures but never quarterly ones, even when the employee is past the wage base and the excess wages are real.

<Warning>
  A `0` in these fields usually means the figure was not calculated for that tax, not that there were no wages. The amounts returned for every tax are `grossWages`, `grossSubjectWages`, `subjectWages`, and `taxAmount`.
</Warning>

## Why the engine needs prior period-to-date figures

Several calculations are impossible without accurate YTD/QTD context:

* **Wage-base limits** — Social Security, FUTA, and SUTA stop taxing once YTD wages cross the annual cap. The engine needs prior YTD to know how much room is left.
* **Progressive brackets & annualization** — cumulative methods (NY, NJ) tax YTD wages and subtract prior withholding, smoothing period-to-period variance.
* **Benefit and contribution limits** — annual 401(k)/HSA caps are enforced against YTD contributions.
* **Additional Medicare** — the extra 0.9% kicks in only after YTD wages cross the threshold.

<Note>
  Because wage bases and limits are annual, **YTD is the most important horizon to get right.** QTD matters for unemployment taxes, which report quarterly. MTD is accepted for the taxes that need it, but never returned. When in doubt, always supply accurate YTD.
</Note>

## Related

<Columns cols={2}>
  <Card title="Gross, subject & taxable wages" href="/ste/core-concepts/wages-gross-subject-and-taxable" icon="money-bill">
    What these amounts represent.
  </Card>

  <Card title="Setting wages" href="/ste/configuration/setting-wages" icon="money-check-dollar">
    Passing period-to-date figures.
  </Card>
</Columns>