Process Payments¶

Process Payments turns approved Vendor invoices and Tenant refund obligations into payment instructions. Preparing and approving an obligation remains separate from authorizing its payment.

Selection and eligibility¶

Open Banking → Process Payments or use Process Payment on an eligible obligation. The workspace supports Vendor-only, Tenant-only, and mixed batches. Source filters help operators focus their work; both sources use the same payment processing and batch controls.

• Vendor invoices must be Approved, Unpaid or Partially Paid, and have a positive remaining balance.
• Tenant payouts must be Approved negative cash Receivables with an unpaid negative remaining balance. Accrual copies, positive invoices with overpayments, zero balances, and already processed obligations are not eligible.
• Tenant payouts pay the full remaining balance of each selected Receivable. Positive charge offsets reduce the refund; different Receivables are not netted against each other. Multiple refunds for the same Tenant remain separate transfers.
• All recorded settlements, including future-dated allocations, reduce the amount available for a payout.

For example, a refund with a $150 credit, a $20 charge offset, and $30 already refunded has a remaining payout of $100. Credence retains the underlying charge accounts and settlement history.

Funding and payment methods¶

Configure funding accounts and methods, review the source documents and amounts, and process the selection. Funding must be compatible with each source property's account relationships, currency, and payment capabilities. Both Vendor payments and Tenant payouts allow per-line funding accounts and methods, with fill-down controls for applying a selection to subsequent lines. Tenant payouts still include the full remaining refund. Each transfer, grouped by source document, funding account, and method, must have a positive net amount; charge offsets must stay with sufficient refund lines to meet this requirement.

Funding suggestions use active accounts in the obligation's currency. Credence prefers a general account on the source property, then the nearest owning entity with an eligible general account. If none is available, it selects the eligible account with the highest last available balance, placing unknown balances last and breaking ties by name and account identifier. Review the suggested account before processing; suggestions do not use payment history.

Funding warnings compare the combined selected payments for each account with its last available balance. Insufficient or unknown balances produce a warning beside the account selections and require confirmation when generating the batch. The balance date is shown when available. You may proceed: balances may be outdated or an account may be funded before bank submission. Unknown balances are not treated as confirmed zero balances.

Incomplete accounting setup, including multiple bank accounts mapped to the same entity cash account, does not exclude the funding account or require confirmation. Active status, property relationships, matching currency, and the banking details needed by the selected method remain required. Payment generation records instructions, not cash ledger entries.

Invoice and refund currency must match the selected funding account; Credence does not infer it from that account.

Tenant payouts support ACH, SEPA, and Danish account transfer when the Tenant's Payment Means and funding account support the selected method. FI-71 remains Vendor-only. Both Vendor payments and Tenant payouts support the manual methods Direct Deposit, Wire, Check, and Other without recipient banking instructions or electronic-payment configuration. Manual methods create payment records but no bank file; arrange payment separately and confirm submission after manual processing.

Missing or invalid recipient instructions, disabled Vendor/Tenant activity during proposed-edit review, incompatible funding, or a changed source obligation prevents processing. No partial batch or payment-status change is retained when generation fails.

Processing and settlement¶

Successful generation creates the batch, its payment records, and any bank files together, and immediately sets the source obligations to Payment in Transit. These records represent instructions—not bank submission or settled cash. Payment amounts retain the same remaining-balance snapshot used in the files.

Download bank files and submit them through your bank. Use Confirm Submission after bank submission or manual processing. Confirmation records the batch's actor and time; it does not post accounting entries or change source payment statuses. Matching actual settlements updates Paid or Partially Paid status.

Estimated funding balances are planning information, not confirmation that the bank will accept or settle a payment. Totals are shown separately by currency.

Batch lifecycle¶

Every cancellation requires a reason and explicit confirmation that the batch was not submitted to the bank, regardless of download history. Credence retains the batch, files, source references, payment amounts, actor, time, and reason. Cancelled status records that confirmation; there is no separate persisted checkbox flag.

Cancellation restores still-in-transit obligations according to their actual remaining balances, without resetting a later payment attempt. Settled or cancelled source statuses are preserved. Cancellation never recalls a bank payment or reverses accounting entries or matched settlements. Repeat submission/cancellation requests preserve their original audit details. Every download route preserves the first download's actor and time.

Retries and exceptions¶

Processing eligibility follows source payment status and remaining balances, not prior Payment or Batch records. Mark Unpaid permits another run under the ordinary approval and funding checks, even when an earlier batch is Submitted. For Tenant payouts, this action is available on an outstanding refund in Payment in Transit. Partial settlement permits processing the unmatched remainder.

Before retrying, establish which transfers the bank will process. Mark Unpaid, invoice cancellation, and creating a new batch do not stop earlier payments or invalidate retained files. Match successful portions before retrying the remainder. Retrying an accepted but unmatched transfer can cause a duplicate payment.

Bank rejection, stop requests, and recall outcomes are not tracked by this workflow. Submitted batches remain Submitted history. Historical batches created before lifecycle tracking also follow the ordinary Submitted rules, without invented submission actors or times.

Remittances¶

Vendor payment-processing notices may be sent before or after submission. They do not confirm bank settlement. Tenant notices are not sent by this workflow.

Cancellation expires pending Vendor notices and retains their history. Sent or in-flight emails cannot be recalled and may still arrive; the cancellation warning does not require a separate acknowledgement.

Access and responsibilities¶

Payables and Receivables retain their normal preparation and approval permissions. Payment processing, bank-file downloads, submission, batch cancellation, and Vendor remittances use the existing payment-processing access across every source property. No additional source-view or party-edit permission authorizes or is required for execution. Merely viewing Payment history does not authorize bank-file downloads.

Changing a source payment status uses that source's existing edit permission. One included obligation's access cannot authorize the rest of a mixed batch. Locating the workspace under Banking does not require bank-feed or reconciliation access.