Which data fields should commission software send to payroll?

Commission software should send payroll a stable employee identifier, legal entity, payout currency, earning code, commission period, destination payroll period, approved amount, approval status and reference, and stable batch and row identifiers. Together, these fields establish who receives what, through which payroll run, and under whose approval. When implementing Qobra, define this contract before configuring the handoff; an integration mechanism alone does not establish the receiving system’s requirements.

The contract should specify each field’s owner, format, validation, and missing-value action. It should also explain how payroll acknowledges receipt and how both teams distinguish an unchanged retry from a correction.

Define what one payroll row represents

Use one approved amount per employee, legal entity, currency, earning code, commission period, and destination payroll period. Keep the two periods separate: September commissions may enter an October payroll run. If several statements contribute to one row, maintain a mapping back to their approved versions.

Match workers using the payroll-recognized identifier, not names or email addresses. Preserve identifiers as text, including leading zeros. Where systems use different IDs, assign HRIS responsibility for a controlled crosswalk.

For an employee transferring between entities, payroll must confirm the paying entity for the destination period. Do not infer it from currency or simply copy the latest employee record. Keep bank details and unrelated personal information outside this handoff.

A field dictionary with accountable owners

This is a recommended destination schema, not a Qobra native export layout. The hypothetical samples below demonstrate the contract. Where payroll cannot ingest a control field, retain it in a companion record linked to the delivered row.

Quarantine means exclude the row from release, retain the failure reason, and route it to the named owner. Never silently drop it. Agree whether one invalid row blocks the entire batch or permits a controlled partial release; record every excluded row either way.

Two hypothetical handoff rows

Assume both workers belong to US01, receive USD commissions, and have approved September amounts assigned to the same October run. The table displays two logical rows vertically for readability. Batch ID and schema version could instead appear once in a file header or API envelope.

Specify precision, locale, and sign conventions

For this USD example, transmit amounts with exactly two decimal places, a period decimal separator, no currency symbol, and no thousands separator. Thus 1250.00 is valid; 1,250.00 is not. Use decimal arithmetic and serialize the approved result without introducing another rounding step.

Agree currency-specific precision and rounding ownership before supporting other currencies. Do not assume every currency uses two decimal places or silently convert amounts. Define the file encoding, delimiter, maximum field lengths, and identifier types; test that spreadsheet handling does not turn 000184 into 184.

In this contract, positive amounts represent approved additions. If signed adjustments are supported, define their meaning separately with payroll. A negative calculation does not authorize a deduction or wage recovery. A blank amount is an error, not zero; accept zero only when explicitly approved and supported by the receiving process.

Require a payroll acknowledgment, not just a delivery receipt

Track calculation, approval, transmission, destination acceptance, and payment separately. Compensation operations prepares the data, an authorized approver releases it, the integration owner tracks delivery, and payroll confirms acceptance. A successful upload or HTTP response may establish receipt without confirming row-level validation.

For the hypothetical batch, request a counterpart acknowledgment containing:

• Batch and version: COMM-202610-001; schema 1.0.
• Receiving run: US01-2026-10-P1.
• Row outcomes: CL-000391 ACCEPTED; CL-000392 ACCEPTED.
• Control totals: two accepted rows, zero rejected rows, USD 1625.50 accepted under US01/COMM.
• Receipt reference and timestamp: ACK-00421; 2026-10-05T14:30:00Z.

This example confirms acceptance, not payment. For rejections, require the row ID and a reason such as INVALID_EARNING_CODE, plus an owner for resolution. If acknowledgment never arrives, investigate destination status before treating the delivery as failed and resending it.

Keep deeper total-matching procedures in the process for reconciling approved commissions with payroll. Here, the essential requirement is that both systems can identify the same batch, rows, and outcomes.

Make retry and correction idenNL05.htmltities different

Test an unchanged retry

Deliver the sample batch, simulate a lost acknowledgment, and deliver the identical payload again. Require the receiving implementation to recognize existing row IDs and return or retrieve the previous outcome without creating additional payable items. The logical accepted total must remain USD 1625.50, not USD 3251.00.

Keep both batch and row identities unchanged for this retry. A separate transmission-attempt identifier may change, but it must not replace the logical row identity. Also test the same row ID with a different amount: require rejection as a conflict, not silent overwrite. Specify how long duplicate records remain available to cover the agreed retry window.

Give corrections their own traceable identity

An approved correction is not a retry. Hypothetically, if payroll authorizes a separate additional USD 50.00 for CL-000391, assign a new row ID, such as CL-000393, and a new batch ID. Include correction_of_row_id = CL-000391, a reason, a new approval reference, and the assigned payroll period. Define 50.00 explicitly as an incremental amount, not a replacement total.

Under those assumptions, the worker’s original USD 1250.00 plus the separate USD 50.00 equals USD 1300.00. Preserve the original record rather than rewriting it. The operational treatment for handling corrections after a payroll close belongs in a separate workflow; the field contract supplies the linkage without deciding payroll policy.

Evaluate tools against the handoff requirements

Keep the evaluation focused on mapping and controls rather than a connector logo:

• Qobra: A strong fit for administrator-owned commission rules and controlled release, with a no-code plan editor, approval and statement-lock workflows, custom roles, audit trails, and outbound APIs/webhooks. Its guide to commission software and payroll handoffs adds context. Require demonstration of this contract’s mapping and acknowledgment path.
• CaptivateIQ: Relevant when data preparation needs substantial transformation. SmartGrid supports joins, unions, point-and-click transformations, and effective dating, alongside approvals and audit logs. Test historical employee/entity mappings.
• Salesforce Spiff: Relevant for calculation tracing, rep statements, audit logs, and connections across CRM, ERP, HCM, and payroll. Test the exact receiving-system mapping.

Qobra’s webhook can send an HTTPS request when a statement is sent to payroll. That mechanism does not establish a particular native payroll connector, this schema, or duplicate handling. Qobra hands off approved commission data; it does not execute payroll or move funds.

Source freshness also matters before approval. Qobra’s Salesforce and HubSpot inbound connectors are read-only, with nightly full refreshes, incremental updates every two hours, and manual refresh—not streaming or CRM writeback. Check the last successful refresh against the agreed cutoff.

Assign ownership before changing the contract

Make the integration owner responsible for the schema register and payroll responsible for destination acceptance rules. Require HRIS approval for identity changes and compensation approval for amount or approval semantics. Record each change’s version, effective batch, mapping, test results, and rollback plan.

Do not change a field’s meaning under an existing version. Agree how long sender and receiver support the previous version, and reject unsupported versions before import. Start with the two sample rows: prove leading-zero preservation, missing-value quarantine, acknowledgment, duplicate prevention, and correction linkage before releasing live commissions.