> ## 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.

# PDFs and tax parameters

> The two things a completed SPF form produces (a signed PDF for your records and structured tax parameters for your payroll system) and what you're responsible for afterward.

Completing a form in SPF produces two results, and you need both. They serve different purposes and go to different places in your system.

<CardGroup cols={2}>
  <Card title="The PDF" icon="file-pdf">
    A filled, signed copy of the official government document. This is the compliance artifact: the thing an auditor asks for and the thing some jurisdictions require you to remit.
  </Card>

  <Card title="Tax parameters" icon="table-list">
    The employee's withholding elections as structured data. This is what your payroll system consumes to withhold taxes correctly from the employee's paycheck.
  </Card>
</CardGroup>

Storing the PDF without applying the tax parameters means you have a signed form and wrong paychecks. Applying the tax parameters without storing the PDF means correct paychecks and no compliance record. You need both.

## The PDF

The completed document comes back as a Base64-encoded string. Decode it and store it as a PDF file according to your retention obligations.

### Signing modes

How the document is signed is controlled by a `signForm` setting with three options.

| Mode              | What you get                                                                                                  | Use it for                                              |
| ----------------- | ------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- |
| `PREVIEW`         | Unsigned, with the SSN or SIN masked and all fields flattened                                                 | Letting the employee review before committing           |
| `SIGN`            | Fully executed, with the employee's name and a date and time stamp on the signature line, SSN or SIN unmasked | The normal path to a completed, filed form              |
| `SIGN_EXTERNALLY` | Unmasked and complete, but with signature and date fields left open                                           | Routing the document through DocuSign or a similar tool |

`PREVIEW` is the default, so if you're expecting a signed form you have to ask for one.

When you use `SIGN`, the timestamp needs a timezone. You can supply one as an IANA identifier such as `America/Chicago`; without it, SPF signs in UTC. See [Interpreting SPF API responses](/spf/api/interpreting-responses) for the header and the handful of forms that use nonstandard signature fields.

### Remitting forms to jurisdictions

Most withholding forms stay in the employer's files. Some don't: a number of jurisdictions require the employer to forward the form, and a few require it within a fixed window. Missouri, for example, expects a copy of the MO W-4 within 20 days of hire.

SPF tells you when this applies through the employer intervention flags described below, but the act of remitting is yours. Retrieve the stored PDF, decode it, and send it to the jurisdiction.

## Tax parameters

Tax parameters are the employee's elections expressed as data your payroll system can act on. Each one is a small object with three fields.

| Field       | What it holds                                                                                         |
| ----------- | ----------------------------------------------------------------------------------------------------- |
| `id`        | Symmetry's name for the parameter, such as `FED.filingStatus` or `AL.totalExemptions`                 |
| `value`     | The employee's answer, or the value their selection maps to                                           |
| `valueType` | The data type of `value`: `dollarAmount`, `boolean`, `text`, `percent`, `integer`, `date`, and others |

Parameter IDs are prefixed by jurisdiction. Federal parameters use `FED.`, state parameters use the state abbreviation, and Canadian parameters use the form name. That prefix is what lets you keep a multi-jurisdiction employee's elections straight when they've completed federal, state, and local forms in one session.

Alongside the form-specific elections, you'll see parameters that describe the *outcome* rather than an answer: whether the employee claimed exemption from federal withholding, whether the form must be filed with the tax authority, and whether employer intervention is needed.

<Info>
  **Mapping is a one-time job.** Every parameter ID and every possible value for a given form is listed in the [SPF catalog](/spf/references/tax-parameter-catalog-and-schema), published with each release. Map them into your payroll system's fields once, then maintain the mapping as forms change.
</Info>

### If you also use the Symmetry Tax Engine

Tax parameters are designed to hand off directly to STE. Symmetry publishes the mapping between the two so you don't have to derive it.

<CardGroup cols={2}>
  <Card title="API tax parameter mapping" icon="right-left" href="/spf/references/ste-tax-parameter-mapping-api">
    Retrieve SPF-to-STE mappings through the API.
  </Card>

  <Card title="Hosted and on-premise mapping" icon="table-columns" href="/spf/references/ste-tax-parameter-mapping">
    The published mapping table for Hosted and on-premise clients.
  </Card>
</CardGroup>

## When the employer has to act

Some employee answers create an obligation for the employer: filing the form with the state, collecting supporting documentation, supplying a certificate number, or signing a section themselves. SPF surfaces this in two parameters:

* **`employerIntervention`**: true when something is required of the employer
* **`employerInterventionReason`**: a code identifying what triggered it, such as a military spouse exemption or a form that must be filed with the state

Route these to whoever handles compliance rather than letting them pass silently into payroll. [Employer form intervention](/spf/references/employer-form-intervention) lists the reason codes per form alongside the jurisdiction's stated expectations.

## How the results reach you

This depends on how you've deployed SPF.

**API clients** get the PDF and tax parameters directly in the response when they submit the employee's answers.

**Hosted and on-premise clients** choose a submission mode. **Postback** delivers a JSON payload to a URL you specify as each form is completed, containing the PDF, the tax parameters, the registration data you supplied, the resolved location data, and a transaction log. **Print** skips the handoff entirely and lets the employee print the form for manual submission. See [Returning completed forms and form data](/spf/hosted-and-on-premise/returning-form-data).

<Warning>
  **SPF doesn't keep any of this.** SPF does not store employee answers, completed forms, or personal data: names, Social Security numbers, and addresses pass through from your request to your response. If you don't capture the PDF and tax parameters when they're returned, they're gone. See [SPF data retention](/spf/references/data-retention).
</Warning>

## Related

<CardGroup cols={2}>
  <Card title="Returning completed forms" icon="inbox" href="/spf/hosted-and-on-premise/returning-form-data">
    Postback and Print modes for Hosted and On-Premise.
  </Card>

  <Card title="Form versions and effective dates" icon="calendar-days" href="/spf/core-concepts/form-versions">
    Why the version a form was completed under matters after the fact.
  </Card>
</CardGroup>
