Software collection playbook
Rippling: payroll register and funding evidence
Payroll approval versus service, funding and settlement.
By Sam Yang · Updated
Which payroll clock is driving the cash decision?
For job cost, align earned labor with the operational period. For cash planning, identify funding events and credits. A run marked completed or approved does not settle both questions.
Evidence basis: Saved payroll export, funding and rendered-spend observations. Current roles and report controls must be verified. Some checks restate Level review safeguards (code rules, not observed vendor behavior).
Check eligible native/API objects, permissions and integration behavior; an integration logo is insufficient.
The run has a future check date
Retain approval and check dates separately and seek funding evidence before calling it paid cash.
A correction changes the required funding
Retain credits and negative components alongside new debits. Adding only positive lines overstates the cash requirement.
Use supported API or native report access for the required scope. A permitted browser session can collect a specific gap. Neither route proves reconciliation or complete costs.
Put the evidence to work
Is the Rippling number earned labor, approved payroll or cash funding?
Keep all three clocks. Service dates support earned labor, run/check dates describe payroll processing, and signed funding evidence explains cash. A correction credit must remain alongside new debits. Card spend and reimbursements are additional populations, not automatically covered by a payroll register.
Build earned labor and payroll funding side by side
- Bind legal entity, run identity, service start/end, check date and run status. Include relevant off-cycle and correction runs.
- Collect the original register, journal/supporting employer cost detail and funding evidence as separate artifacts. A comparison report is not the register.
- Allocate earned labor using actual service/time evidence. Do not shift all cost to the check date or assume the period after the last run has zero cost.
- Reproduce signed funding debits and correction credits, then verify the corresponding bank occurrences separately.
Bring to the review: An earned-cost view and a signed funding view connected by run identities.
Then decide: Resolve missing burden, dates or credits before job-margin analysis or funding decisions.
Investigate reimbursements without double-booking cash
- Determine whether the question concerns purchase expense, reimbursement approval or bank funding.
- Retain the exact reimbursement batch and its entity, batch identity, debit/payout dates and signed total; use original receipt evidence when available.
- Inspect employee expense detail for actual purchase/trip dates. A mileage route need not have a supplier invoice.
- Match the batch funding to the already posted bank occurrence and keep unresolved employee items distinct.
Bring to the review: Purchase-period expense detail linked to a separately evidenced funding batch.
Then decide: Review existing ledger entries before proposing an expense entry; never recreate a bank movement already represented.
Which collection route answers this question?
Choose the route for the missing evidence and the access available in your account. The comparison below distinguishes documented coverage from coverage that still needs checking.
Supported API
- What it supplies
- Rippling maintains an official developer portal. This investigation did not verify a payroll-register endpoint or complete original-report response for the required account.
- What still needs proof
- Current endpoint, permission, entity scope, correction history and original register coverage remain unverified. Portal availability is not endpoint coverage.
Choose it when: An existing authorized integration proves it supplies the exact register/funding population.
Native export
- What it supplies
- Saved October 2026 collection evidence distinguishes native Payroll Register from comparison exports, and records original-file delivery per run.
- What still needs proof
- A visible Download control does not prove a file landed; current report menus and role entitlements remain account-specific.
Choose it when: Collect the original register for a precisely identified run and preserve its selection witness.
Permitted browser
- What it supplies
- Reusable saved collectors bind entity/run, retain full rendered populations and report partial export failures. The observed register collector selects by check date or overlapping service period.
- What still needs proof
- Completed payroll-list evidence does not certify card-spend, reimbursement or bank populations. Missing or stale controls remain explicit failures.
Choose it when: The original required report is browser-backed and verified existing access does not supply it.
Reproduce the diagnostic
Fictional correction credit changes funding
All records and amounts below are fictional teaching inputs. This example demonstrates the calculation, not a customer outcome or a reproduced software defect.
Positive funding is 2500, but the signed requirement is 2500 - 400 = 2100. The 400 credit changes funding, not necessarily current-period earned labor. This simplified fixture is a signed funding bridge, not a complete payroll journal.
What the CSV columns mean
- component: new_debit or correction_credit
- run_id: fictional run identity
- signed_funding: USD debit requirement, credits negative
- New debit
- 2500 USD
- Positive funding component before the credit.
- Signed funding requirement
- 2100 USD
- Required funding after this fixture's correction credit.
- Overstatement if credit omitted
- 400 USD
- Difference caused by summing only positive components.
Inspect rippling-funding.csv
run_id,component,signed_funding run_demo,new_debit,2500 run_demo,correction_credit,-400Download this CSV
Next decision: Seek the identified run funding and actual bank occurrence. Collect separate service-period costs before calculating job margin.
Run the example locally
Save the CSV files, expected-results.json and reproduce.mjs in one folder. With Node.js installed, run the command below. It calculates the checks from the CSV bytes and rejects a changed input or expected result.
node reproduce.mjs expected-results.json
No software login, customer records or API key is required.
When the result does not make sense
Completed payroll does not equal the bank debit
Check: Inspect funding date, check date, signed corrections and separate funding components.
Resolve the question: Produce a run-to-funding bridge and retain pending settlement until bank evidence exists.
Export has totals but no required employer cost detail
Check: Verify whether a comparison export was selected instead of the Payroll Register, then inspect supporting journal detail.
Resolve the question: Collect the required native register/supporting report rather than assuming missing burden is zero.
A reimbursement is absent from Billing Payments
Check: Check the exact reimbursement batch and team expense population; saved observations found these distinct from Billing Payments.
Resolve the question: Preserve batch and expense identities, then investigate funding separately without declaring payment absent.
Where automation earns its place
Good work for automation
- Bind exact entities and run identities, preserve signed corrections and collect the original selected report with explicit partial outcomes.
Keep a person on these decisions
- Determine accrual timing, labor allocation, burden coverage and the accounting treatment of corrections or reimbursements.
References behind these workflows
Product documentation supports the specific scope stated beside each source. Level's diagnostic methods and fictional calculations remain distinct from vendor capabilities.
- Rippling developer portal
Official portal existence only. Specific payroll endpoint and permissions were not verified. Reviewed .
Collect and verify the population
- Payroll register
- Keep entity, run identity, service dates and check date. Comparison export is a different artifact.
- Funding and journal detail
- Preserve correction history and employer burden; missing register fields require supporting reports, not an assumed zero.
- Card spend detail
- Bind each native transaction identity and actual Total; purchase date and Finalized on can differ. Ambiguous USD displays cannot support a definitive aggregate.
Select the correct entity, payroll run and service/check dates. Retain the complete register, funding and credits. Check all rows, including those beyond the visible grid. Collect card evidence separately.
Dated collection sequence
Dated saved collection procedure reviewed October 6, 2026. Verify the current account, interface, permission and available reports. Menu names may differ.
- Verify company and payroll entity, then open Payroll > Overview > Completed.
- Retain run links, entity, service-period dates, check date and status. Completed can include an approved run with a future check date.
- Open the run Payroll Summary > More Options > Payroll register.
- Select Download in the register panel. In the second dialog choose CSV, deselect PDF if unnecessary, leave grouping None, then Download report.
- Retain the original file and separate funding, employee and tax evidence. Export pay run comparison is a different control and does not replace the register.
- If a correction preview lacks the register control, retain complete visible evidence and explicitly mark missing export coverage.
Evidence acceptance checklist
- Select the entity, run, earned period and check date explicitly.
- Retain complete register, funding and credit populations beyond the visible grid.
- Collect card activity under a separate source and coverage manifest.
Fictional collection example
A fictional payroll register is approved before funds settle, and a funding credit reduces the debit. Return approval, earned labor, gross funding and credit as separate facts. Treating the net bank debit as another payroll expense can obscure the original journal and liability flow.
Invented teaching scenario, not a customer result or a reproduced vendor defect.
Capture the setup with the evidence
- Company, legal entity or account, report name, period, basis, currency and timezone.
- Selected filters, status, page count, original record identifiers and control totals.
- Collection time, source route and authorized role. Record browser and automation versions when using a browser.
- Original files and exceptions. Keep credentials, customer identifiers and financial artifacts private.
A browser version helps reproduce an interface issue. It does not validate the financial conclusion.
Pitfalls and stop conditions
Approval, earned labor and paid funding are different events. Payroll and card grids need separate coverage checks. Funding credits must remain explicit.
How a plausible answer can go wrong
A full payroll register does not complete card spend, and an approved correction does not prove the bank debit occurred. Visible card rows or a row showing two dollar values also cannot certify the whole spend total.
Stop if account identity, permission, cutoff or population is uncertain. Return the missing evidence for review. Do not fill the gap with an invented record, a balancing entry or an assumed zero.
Read-only AI collection prompt
Replace the bracketed scope before use. This prompt collects evidence; it does not permit edits, approvals or accounting execution. Requesting an emailed report is a separate account action and requires explicit authorization.
Collect read-only evidence for Rippling to answer [financial question]. Confirm [company], [account/entity], [period], [basis], [currency] and [allowed reports]. Select the correct entity, payroll run and service/check dates. Retain the complete register, funding and credits. Check all rows, including those beyond the visible grid. Collect card evidence separately. Retain original files, complete record IDs, counts, filters, collection timestamp and exceptions. Approval, earned labor and paid funding are different events. Payroll and card grids need separate coverage checks. Funding credits must remain explicit. Stop if the source or scope is uncertain. Do not post, match, reconnect, delete or change settings. Return the evidence for financial review; do not claim the books are correct. Do not approve, submit payroll, pay, transfer, refund, send messages, invite users or accept terms. Stop at any login, MFA or credential prompt and hand back to the account owner. Store files only in [approved private location]. Do not paste customer artifacts into public tools. Use only preauthorized collection actions. Request an emailed report only when its delivery is explicitly authorized; otherwise ask the account owner to supply the file.
Next decision
What does the evidence support?
Give the owner separate earned-cost and funding views, with unresolved credits or missing native totals named. Do not turn a status label into a settled-cash assertion.
Compare the same population, identities and cutoff. Keep unsupported costs or settlements visible before using the result for pricing, cash or close.
Open the financial acceptance guide →Sources and scope
Base product-reference scopes were reviewed . The collection procedure retains its own review date in the dated sequence above. Individual source rechecks are dated with their citations. Operator decision guidance was reviewed 2026-10-07. The references below support their stated product scope, not every observed interface detail. It is not a vendor capability certification, a measured customer result or an independently reconciled account. Verify current features and entitlement in the account you use.
- Rippling API access and authorization reference
API access reference, not payroll or card coverage certification.