26.8.0

Added

• Real-time TIN Match feature: POST /avalara1099/tin-matches/$real-time
• Supported 1099 Forms and 1042-S: Added a nullable tinType field that classifies the recipient. New preferred values are INDIVIDUAL, BUSINESS, and UNKNOWN. The field is optional (may be omitted or sent as null); input is case-insensitive and output is UPPERCASE. On the wire to the downstream IRIS/Ruby service, a null/omitted tinType is sent as UNKNOWN; on read, a null, empty, or missing downstream value maps back to null (it is never coerced to UNKNOWN). Legacy identifier values (EIN, SSN, ITIN, ATIN) remain accepted for backward compatibility. Applies to POST /1099, PUT /1099, $bulk-upsert, and GET /1099, including Form 1042-S on all paths (the CSV-based $bulk-upsert now carries tinType and the individual name fields for 1042-S).
• 1099 and 1042-S Forms: Added firstName, middleName, lastName, suffixName, businessName, and businessName2 fields.
• Issuers (Payers): Added tinType (INDIVIDUAL, BUSINESS, UNKNOWN — defaults to UNKNOWN when omitted, sent as null, sent as an empty/whitespace string, or sent as a non-empty unrecognized value (e.g., "FOO" or a typo like "INDIVIDUL"); input is case-insensitive, output is UPPERCASE to match Forms 1099 typeOfTin), firstName, middleName, lastName, and suffix fields on POST/PUT/GET /1099/issuers. When tinType=BUSINESS, businessName is required; when tinType=INDIVIDUAL, firstName and lastName are required, and businessName/businessName2 must be empty. Existing payloads that send only name/dbaName continue to work unchanged (the response returns tinType: "UNKNOWN"), and legacy records with NULL type_of_tin are also returned as UNKNOWN.
• Issuers (Payers): Added businessName and businessName2 as the canonical aliases for name and dbaName on POST/PUT/GET /1099/issuers (non-breaking; same shape as Forms 1099). Both names map to the same underlying value; responses include both keys. When both legacy and canonical keys are sent in the same request body, the last one in the JSON document wins. OData $filter and $orderBy on GET /1099/issuers accept businessName / businessName2 natively (case-insensitive) and continue to accept the legacy name / dbaName tokens silently (alias resolved at parser time). Internally, the Issuer domain entity properties were renamed to BusinessName / BusinessName2; the underlying PostgreSQL columns (name, payer_name_2) are unchanged.
• Issuers (Payers): Added support for filtering and sorting by firstName and lastName on GET /1099/issuers.
• Issuers (Payers): Extended the immutability rule on PUT /1099/issuers/{id} for issuers with scheduled Forms 1099: tinType, firstName, middleName, lastName, and suffix are now blocked alongside tin and name. dbaName remains editable.

Deprecated

• Supported 1099 Forms and 1042-S: The tinType values EIN, SSN, ITIN, and ATIN are deprecated. The platform is transitioning from tax-identifier classifications (identifier formats) to recipient-entity classifications (INDIVIDUAL, BUSINESS, UNKNOWN). The deprecated values remain supported for backward compatibility only; new integrations should use the recipient-entity values.
• Issuers (Payers): name and dbaName on POST/PUT/GET /1099/issuers are deprecated in favor of businessName and businessName2. They will continue to be accepted on input and emitted on output for backward compatibility.

Removed

• BREAKING CHANGE — Form 1042-S: Removed the entityType field. Its downstream type_of_tin slot is now driven by the inherited tinType (TinType1099) field. Clients that sent entityType: "INDIVIDUAL"/"BUSINESS" should send tinType with the same value.
• BREAKING CHANGE — Forms 1095-B and 1095-C: Removed tinType from the request/response schema. These forms do not classify a recipient TIN and must not expose tinType.
• 1095 Forms: Removed accountNumber, officeCode, noTin and secondTinNotice fields.

Changed

• BREAKING CHANGE — Issuers (Payers): POST /1099/issuers now returns HTTP 201 Created and PUT /1099/issuers/{id} now returns HTTP 200 OK with a validationErrors[] array in the response body when field-level business validation fails, instead of HTTP 400 Bad Request. The issuer is persisted (POST) or updated (PUT) regardless of business-rule validation outcome. Each entry in validationErrors[] identifies the affected field (camelCase) and one or more errors messages. JSON parse errors (malformed body, wrong type tokens), authentication failures, authorization failures, the user-account pre-condition, and taxYear validation failure on POST (missing or out-of-range) continue to return HTTP error status codes (taxYear is rejected upfront because it is immutable on update — see IssuerBase.TaxYear). On PUT, the identity-change rule (TIN, TIN type, or name change rejected when the issuer already has scheduled Forms 1099) continues to return HTTP 400 Bad Request — same rationale as the POST taxYear carve-out: persisting that change would corrupt the IRS audit trail. Note: a non-empty unrecognized tinType string (e.g., a typo such as "INDIVIDUL") is not a parse error — it is silently coerced to UNKNOWN per the tinType contract documented above (mirrors Ruby type_of_tin semantics).
    - Customer Impact: Clients that previously branched on HTTP 400 from POST /1099/issuers or PUT /1099/issuers/{id} to surface validation errors (or to assume the record was not saved/updated) must update to (1) treat HTTP 201 (POST) / HTTP 200 (PUT) as a possible "validation failed" outcome and (2) read validationErrors[] from the response body. Existing payloads that passed validation are unaffected — they still return HTTP 201 / 200 with validationErrors as an empty array.
• Issuers (Payers): Aligned field-level validation on POST/PUT /1099/issuers with the canonical Payer rules. Newly enforced: individual name fields (firstName, middleName, lastName, suffix) are capped at 20 characters, address is required and must contain at least one alphanumeric character, and tin must contain exactly nine digits (extra characters are rejected). Relaxed: state is required only when countryCode is US or CA; US ZIP codes accept the +4 with or without a separator (e.g., 123456789); Canadian postal codes accept an optional space and are case-insensitive (e.g., K1A0B1); and email addresses accept top-level domains longer than three characters (e.g., .info). These outcomes are reported through validationErrors[] (HTTP 201/200), consistent with the issuer validation-errors behavior above.
• BREAKING CHANGE: The IRS system for e-filing 1099 forms is changing in January of 2027 and now requires that the name of the 1099 recipient be split into first/middle/last/suffix if the recipient is an individual.
    - DEPRECATED: The recipientName and recipientName2 fields are now deprecated.
    - For backwards compatibility, the Avalara 1099 API will continue to support the above deprecated fields, but if the recipientName field is used and the 1099 recipient is an individual, Avalara will parse that field into firstName, middleName, lastName and suffixName. Please confirm all data prior to Avalara filing with the IRS.

26.5.0

Added

• Forward-compatible 1099 schemas (SDK stability): 1099 form schemas (1099-NEC, 1099-MISC, 1099-DIV, 1099-INT, 1099-K, 1099-R, 1042-S, 1095-B, 1095-C, W-2) now publish additionalProperties: true in the OpenAPI document. SDKs generated from this version (and later) will safely ignore unknown JSON properties on the wire. Going forward, adding a new optional attribute to any 1099 form is no longer a breaking change — existing SDK clients keep working when the server adds new fields, and clients can stay within the same MAJOR version range.
• Support for W-2 form type across all endpoints:
  • POST /avalara1099/1099/forms – Create new W-2 forms
  • PUT /avalara1099/1099/forms/{id} – Update existing W-2 forms
  • DELETE /avalara1099/1099/forms/{id} – Delete W-2 forms
  • GET /avalara1099/1099/forms – Retrieve all forms, including W-2
  • GET /avalara1099/1099/forms/{id} – Retrieve specific W-2 form by ID
  • GET /avalara1099/1099/forms/{id}/pdf – Download PDF for a W-2 form
  • POST /avalara1099/1099/forms/$bulk-upsert – Bulk upsert W-2 forms
• Form 1042-S: Added withholdingRatePoolIndicator field (Box 7d) - indicates if this Form 1042-S is being filed to revise an amount subject to withholding in a withholding rate pool to report to a specific recipient
• Form 1042-S Income Code: Added support for new income codes:
  • 59: Consent fees
  • 60: Loan syndication fees
  • 61: Settlement payments
• Form 1042-S Chapter 3 Status Code: Added support for new Chapter 3 status codes:
  • 40: Partnership QDD
  • 41: U.S. government entity or tax exempt entity (other than section 501(c) entities)

Changed

• BREAKING CHANGE: W-forms state/province fields updated from enum (StateCode) to string where applicable (non-US codes, consistent serialization).
  • W9 state:
    • POST/PUT /avalara1099/w9/forms: request field state changed from enum (StateCode) to string.
    • GET /avalara1099/w9/forms and GET /avalara1099/w9/forms/{id}: response field state returns the stored code string directly (for example, AB) instead of enum-derived values.
    • Swagger/OpenAPI schema for W9 state no longer exposes enum values.
  • W4 state:
    • POST/PUT /avalara1099/w9/forms: request field state changed from enum (StateCode) to string for W4 form payloads.
    • GET /avalara1099/w9/forms and GET /avalara1099/w9/forms/{id}: W4 response field state returns the stored string (same as W9).
    • Swagger/OpenAPI for W4 state uses string (with EntityConstants.StateCodes-based hints where applicable), not enum.
  • W8-BEN-E residenceState, mailingState, disregardedState:
    • POST/PUT /avalara1099/w9/forms: these request fields changed from enum (StateCode) to string for W8-BEN-E payloads.
    • GET /avalara1099/w9/forms and GET /avalara1099/w9/forms/{id}: same fields already returned as strings from persistence; clients should send string codes (for example, CA) instead of numeric enum values in JSON.
    • Swagger/OpenAPI uses string with EntityConstants.StateCodes+CaProvinceCodes hints (unchanged reference), not enum.
  • SDK impact: generated SDKs represent W9 state, W4 state, and W8-BEN-E residenceState / mailingState / disregardedState as string instead of enum.

26.4.0

A1099 Updates:

• BREAKING CHANGE: W-forms state/province fields updated from enum (StateCode) to string where applicable (non-US codes, consistent serialization).

  • W9 state:
    • POST/PUT /avalara1099/w9/forms: request field state changed from enum (StateCode) to string.
    • GET /avalara1099/w9/forms and GET /avalara1099/w9/forms/{id}: response field state returns the stored code string directly (for example, AB) instead of enum-derived values.
    • Swagger/OpenAPI schema for W9 state no longer exposes enum values.
  • W4 state:
    • POST/PUT /avalara1099/w9/forms: request field state changed from enum (StateCode) to string for W4 form payloads.
    • GET /avalara1099/w9/forms and GET /avalara1099/w9/forms/{id}: W4 response field state returns the stored string (same as W9).
    • Swagger/OpenAPI for W4 state uses string (with EntityConstants.StateCodes-based hints where applicable), not enum.
  • W8-BEN-E residenceState, mailingState, disregardedState:
    • POST/PUT /avalara1099/w9/forms: these request fields changed from enum (StateCode) to string for W8-BEN-E payloads.
    • GET /avalara1099/w9/forms and GET /avalara1099/w9/forms/{id}: same fields already returned as strings from persistence; clients should send string codes (for example, CA) instead of numeric enum values in JSON.
    • Swagger/OpenAPI uses string with EntityConstants.StateCodes+CaProvinceCodes hints (unchanged reference), not enum.
  • SDK impact: generated SDKs represent W9 state, W4 state, and W8-BEN-E residenceState / mailingState / disregardedState as string instead of enum.

  E-Invoicing:

  • Including version 1.5 and 1.6 of the API into the SDK for consumption

25.11.2

Added

• 1099-R Distribution Code Y: Added support for "Qualified charitable distribution (QCD) claimed under section 408(d)(8)" - available for tax year 2025 and later
• 1099-NEC and 1099-MISC forms: Added support for localityId field

Changed

• BREAKING CHANGE: Field name changes for all 1099 forms:
  • localityIdNumber renamed to localityId
  • stateIdNumber renamed to stateId
• BREAKING CHANGE: ValidationError schema update - added errorCodes field (reserved for future use)

25.11.1

Added

• 1099-R Distribution Code Y: Added support for "Qualified charitable distribution (QCD) claimed under section 408(d)(8)" - available for tax year 2025 and later

Changed

• Golden Parachute Excess Payments field availability:
  • 1099-NEC forms: Field now available for tax year 2025 and later
  • 1099-MISC forms: Field restricted to tax year 2024 and earlier (validation error if used for 2025+)
• Issuer API validation changes:
  • Email field: Made optional (no longer required). Phone will be used for communications if email is not specified.
  • TaxYear field: No longer required on update operations. Tax year is preserved from existing issuer and cannot be modified on update.
  • City and State fields: Now required on create and update.
  • TransferAgentName field: Added maximum length validation (40 characters).
  • ReferenceId field: Added maximum length validation (50 characters).

Fixed

• SDK: POST /avalara1099/forms1099 : fix 400 (Bad Request) error when creating 1099 forms while attempting to verify supported form types.
  • Supported types: 1099-NEC, 1099-MISC, 1099-DIV, 1099-R, 1099-K, 1095-B, 1042-S, 1095-C, 1099-INT

Removed

• CoveredAllMonths field removal:
  • Removed coveredAllMonths field from CoveredIndividual model in Form 1095-B and 1095-C APIs
  • API requests containing deprecated coveredAllMonths field will be accepted but the field will be silently ignored (has no effect)
  • API responses no longer include coveredAllMonths field
  • Required action: Clients must migrate to individual month coverage fields (coveredJanuary, coveredFebruary, etc.)
  • Affected endpoints: All Form 1095-B and 1095-C CRUD operations (CREATE, READ, UPDATE, BULK UPSERT)
  • Note: While requests with this field won't error, the field is deprecated and will not function. Clients should update to use individual month fields.

25.11.0

Added

• Endpoint: GET /w9/forms/{id}/pdf – Generate and download PDF files for W9 forms.
  • Note: Currently supports W9 forms only.

Changed

• Golden Parachute Excess Payments field availability:
  • 1099-NEC forms: Field now available for tax year 2025 and later
  • 1099-MISC forms: Field restricted to tax year 2024 and earlier (validation error if used for 2025+)

25.10.1

A1099

Added

• Endpoint: GET /w9/forms/{id}/pdf – Generate and download PDF files for W9 forms.
  • Note: Currently supports W9 forms only.

Changed

Fixed

• Fixed bulk upsert job status counts not updating for batches >1000 forms. Job status now correctly reports totalRows, totalProcessed, createdValid, etc. after asynchronous processing completes.

25.10.0

Changed

• BREAKING CHANGE:
  • Consolidated error response models - ErrorResponse and ErrorResponseItem - for all API endpoints and all types of errors.
    Example:

    {
        "title": "One or more validation errors occurred.",
        "errors": [
            {
                "type": "referenceId",
                "detail": "'Reference Id' must not be empty."
            }
        ]
    }
    

Fixed

• POST/PUT /avalara1099/w9/forms: fix 500 (Internal Server Error) for W9 form type when trying to check if TIN match is allowed with user account on trial period.

25.9.0

A1099

Changed

• PUT /avalara1099/w9/forms/{id}:
  • Handles TIN match for W9s as POST /avalara1099/w9/forms do.
  • Re-sends form request e-mail when e-mail address is updated (only for forms in 'requested/bounced' status).
• BREAKING CHANGE:
  • PUT /avalara1099/w9/forms/{id}: request and response models changed to match same models used on POST endpoint.

Fixed

• Fix invalid updates on PUT /avalara1099/w9/forms/{id}:
  • It was allowed sending "id" parameter and "type" body attribute related to different form types.
  • New behaviour: returns 400 Bad Request if both information are not related to the same form type (e.g., "W9").
• Fix missing "type" attribute for W9s response bodies (POST /w9/forms, GET /w9/forms/{id}).

25.8.4

• Fix to always respect passed in X-Avalara-Client header #25