xMatix
Sign in Request demo
xMatix
PRODUCTS
SalesField SalesCRMRewardsClaimsInventoryProcurementWarehouse ManagementField ServiceServiceSupportTelephony & MessagingFinance & AccountingPayrollExpense ManagementCommercePortalsAnalytics & ReportingData StudioMobile AppSee all products →
PLATFORM
Platform overviewApp BuilderAutomationIntegrationsSecurity & GovernanceChange ManagementDevelopers
SENSE AI
Sense AI overviewSense AssistSense ControlSense VisionAI StudioTrust & governanceIn Claude & ChatGPTUse cases
SOLUTIONS
FMCG & DistributionManufacturing & Dealer NetworksAutomotive & DealershipsPharma & HealthcareConsumer DurablesAgri-InputsBuilding MaterialsService NetworksWarehousing & 3PLFinancial AccountingERP SoftwareIndia GST ComplianceUAE VAT & e-InvoicingSaudi ZATCA & VATAll solutions →
RESOURCES
Knowledge CenterDeveloper & CLIBlogGuidesWhat is xMatix?Company facts
COMPANY
AboutCareersPartnersEventsContactAuthorsLegal
Sign in Request demo
Home/Docs/Entity Reference/Payroll Run — entity reference
REFERENCE · Last reviewed

Payroll Run — entity reference

One execution of payroll for a PayrollPeriod, and the header that drives the whole chain: Project TDS, Calculate, Post, Generate Payslips, Generate Payment. It owns per-employee PayrollRunDetail summaries, per-component PayrollRunComponentLine rows (the calculation truth), the Payslips generated from those details, and the LoanAdvanceRecovery rows for installments recovered in this run. Three status fields move independently: Status is the business lifecycle (Draft, InputsLoaded, Calculated, Review, Approved, Posted, PaymentGenerated, Paid, Closed, Reversed), ApprovalStatus mirrors the approval engine, and PayrollPostingStatus plus GLId record whether the accrual journal exists — never infer posting from Status alone. Recalculating REPLACES the previous pass rather than appending, and is refused outright once the run is posted or its payslips are published.

Fields

FieldLabelTypeRequiredWhat it does
ApprovalStatusApproval StatusPickListA mirror of the approval engine's outcome on this run — Approved, Rejected, Pending, or cleared to null on recall — written by the approval bridge, not by the payroll engine. It matters because a final Approved decision also posts the run's accrual to the ledger automatically, unless the run is already posted, so this field moving to Approved usually means a journal was created.
BranchIdBranchLookup → BranchThe branch dimension copied onto the payroll journal, its lines and every Payroll-Payable open item raised by posting. It is not used to filter which employees are included — the calculation selects on company, not branch.
BusinessUnitIdBusiness UnitLookup → BusinessUnitA dimension carried through to the Payroll-Payable open items raised at posting. It does not appear on the journal lines and does not affect which employees are calculated.
CreatedByIdCreated ByLookup → UserAccountYes
CreatedDateTimeCreated DateDateAndTimeYes
GLIdGLLookup → JournalThe payroll accrual Journal this run posted. It is a posting gate as much as a link: a run with any value here is treated as posted and will refuse both a second post and a recalculation, even if PayrollPostingStatus says otherwise.
IdIdGuidYes
ModifiedByIdModified ByLookup → UserAccountYes
NameNameTextYes
OwnerIdOwnerLookup → UserAccountYes
PartnerAccountIdPartner AccountLookup → AccountThe company whose payroll this run is, and the selector for the whole calculation: employees are picked up when their payroll company or their own company matches it, and the bank, Payroll-Payable control account and fiscal-year window for year-to-date figures are all resolved under it. A run left without a company cannot derive a bank account and fails when a payment batch is generated.
PaymentBatchIdPayment BatchLookup → PayrollPaymentBatchThe salary batch that actually disbursed this run's net pay. It is stamped only when the batch is paid, not when it is generated, so a run can have a Draft PayrollPaymentBatch pointing back at it while this is still empty.
PayrollPeriodIdPayroll PeriodLookup → PayrollPeriodThe pay cycle this run belongs to, and the key input to nearly every step: it supplies the start and end dates used for proration and loss of pay, the pay date the accrual journal is dated with, the period whose approved adjustments are pulled in, and the period whose TDS projections the calculation reads. A run without it still calculates, but with no proration, no adjustments and no TDS, and it cannot prepare a statutory challan.
PayrollPostingStatusPayroll Posting StatusPickListValues: Not Posted, Posted, Reversed, Failed.
PeriodPeriodPickListYesValues: January, February, March, April, May, June, July, August, September, October, November, December.
ProcessedResourcesProcessed ResourcesNumberHow many employees actually produced a PayrollRunDetail in the last calculation pass. Stamped by the calculation and not kept live, so it goes stale if details are deleted by hand afterwards.
RecordTypeIdRecord TypeGuid, hidden
SkippedResourcesSkipped ResourcesNumber
StatusStatusPickListYesThe run's business lifecycle stage, from the vocabulary Draft, InputsLoaded, Calculated, Review, Approved, Posted, PaymentGenerated, Paid, Closed and Reversed. Note also that the seeded approval process stamps its own values, Pending Approval on submission and Processed on final approval, which is why those two appear in the picklist even though no engine constant matches them. Values: Draft, PendingApproval, Inputs Loaded, Calculated, Processed, Review, Approved, Posted, Payment Generated, Paid, Closed, Reversed.
SubscriptionKeySubscription KeyGuid, hiddenYes
TotalNetPayTotal Net PayCalculated (calculated)The sum of every processed employee's net pay, stamped by the calculation at the end of a pass rather than maintained as rows change. It reflects the last calculation only — it is not adjusted by posting, by the payment batch, or by editing a component line afterwards.
TotalResourcesTotal ResourcesNumberHow many active, non-exited employees of the run's payroll company were considered in the last calculation pass — the denominator, not the number paid. Compare it with ProcessedResources and SkippedResources to see whether the run covered everyone.
UpdatedDateTimeModified DateDateAndTimeYes

Actions

ActionLabelTypeWhat it does
BulkDeleteDeleteDeleteDelete the selected records.
CalculateRunCalculateServerAction (CalculatePayrollRun)Calculate the payroll run.
CloneCloneServerAction (Clone)Create a copy of this record
DeleteDeleteDeleteDelete
DeleteRecordDeleteDeleteDelete
EditEditEditInlineEdit
EditListRowEditEditEditListRow
EditRecordEditEditEdit
Form16Form 16ServerActionForm16
GeneratePaymentBatchGenerate PaymentServerAction (GeneratePaymentBatch)Generate the salary payment batch.
GeneratePayslipsGenerate PayslipsServerAction (GeneratePayslips)Generate payslips for the run.
NewNewNewNew
PostPayrollPost PayrollUIActionPost Payroll
PostRunPostServerAction (PostPayrollRun)Post the payroll accrual to the ledger.
PrepareSalaryTdsChallanPrepare TDS ChallanServerAction (PrepareSalaryTdsChallan)Drafts the period's salary-TDS deposit challan by totalling the tax on every POSTED payroll detail of the same company and period — not just this run — and creating a pending challan for that amount. Re-running is safe: an existing pending challan for the period is refreshed to the new total, while one already deposited is left untouched and instead reports the difference for a separate deposit. It fails when the run has no payroll period or when no posted TDS exists yet, so post the payroll first.
PrintPrintServerActionPayroll slip print
ProjectTdsProject TDSServerAction (ProjectTds)Project salary TDS for every employee in this run.

Lookup filters

FilterLookup fieldNotes
BranchFilterBranchIdBranchFilter
PartnerAccountFilterPartnerAccountIdPartnerAccountFilter