Payment batches and transaction journals

Financial Data Operations supports two controlled bulk-posting layouts:

• Payment Batch: one funding account pays many beneficiary accounts;
• Transaction Journal: one or more balanced Transactions, each with its own Debit and Credit lines.

These are operational posting tools. They are separate from the general Imports / Exports area.

Permissions and scope

Complete Before processing the first transaction before validating an operational upload.

You need Create Financial Transaction Upload to download a template, upload a completed file, validate it, and submit your own staged job. The maker must have an assigned Branch. Viewing jobs requires Read Financial Transaction Upload, and downloading results requires Export Financial Transaction Upload.

Approval requires the permission for the displayed level: Approve L1, Approve L2, or Approve L3 for Financial Transaction Upload. The maker and every approver must be different users.

The upload records the maker's company, Branch, role, Branch restrictions, and data-access scope. Those captured access details govern which jobs and posting data the user can access.

Prepare the file

1. Open Processing & Monitoring → Financial Data Operations → Transaction Uploads.
2. Select New Transaction Upload.
3. Select Payment Batch or Transaction Journal.
4. For a system administrator, select the Company.
5. Select the company's current working day as the Posting Date. The Value Date is set to the same date; these operational uploads do not support a different Value Date.
6. Select the header Branch.
7. Complete the layout-specific context, then select Download selected template.

Do not rename template columns or worksheets. Complete the downloaded template and retain a unique source reference for each payment or journal Transaction.

Payment Batch

Select the Funding Account, authorized Transaction Code, Currency, and Default Narrative. Upload the CSV template with one row per beneficiary payment.

Identify a beneficiary with an account number, another supported account reference, or an external reference. Enter the Amount and optional source reference, row Narrative, and Cost Centre. A row Narrative overrides the Default Narrative.

Rows that remoteEaze groups into the same posting batch must not specify conflicting Cost Centres. Use one Cost Centre for that batch or leave the field empty consistently.

remoteEaze builds balanced postings by debiting the shared Funding Account and crediting the beneficiaries. Large files may be divided into more than one balanced Transaction during validation.

Transaction Journal

Upload the XLSX workbook. Use:

• transactions for each source Transaction key, source reference, and header Narrative;
• transaction_lines for its batches and Debit or Credit lines.

Every source Transaction needs at least two lines. Each batch and the complete file must balance in the company base currency. Account and Transaction Code references may use the reference types shown in the template; external references also require their external system code and key.

The journal batch Cost Centre is copied to its posting lines as an immutable Code and Name snapshot.

Validate and review

1. Upload the completed CSV or XLSX file.
2. Select Validate File.
3. remoteEaze creates a job in Validating and opens Transaction Upload Review.
4. Wait for validation to finish, then review the Projected Posting Plan, totals, and every row under Validation Rows.
5. Filter rows by status or open a row to inspect its source values, normalized values, errors, warnings, and generated Transaction reference.
6. Select Download Results when a full CSV result report is needed.

The job becomes Ready for review only after preflight succeeds. It cannot be submitted while any row is Invalid or when there are no valid rows. Correct the source file and start a new upload job when validation fails; staged rows are not edited in remoteEaze.

Submit, authorize, and post

The upload maker selects Submit for Approval. remoteEaze follows the configured path, descending L3 → L2 → L1 when all three levels are required. Final authorization changes the job to Posting and starts background posting from the validated plan.

The final status is:

• Completed when every planned row posts successfully;
• Completed with errors when some rows post and others fail;
• Failed when the job itself cannot complete.

Open the job to compare Valid, Invalid, Posted, and Failed counts. Posted rows link to their generated Transactions, and Download Results includes the row-level outcome. Reject and Deny both close that upload job; a rejected file is not edited or resubmitted in remoteEaze. Correct the source and create a new upload when another attempt is required.

Do not upload the same source file again while it already has an active job. remoteEaze also assigns deterministic posting identities so background retries do not intentionally create duplicate Transactions.