Reference · built on requestOperator by FibricFinance & billing

Cash Application

Incoming payments and remittance advices matched to open invoices, with each application, short pay, and on-account balance proposed.

Request accessPricing ↗

About

Money arrives with less information than the invoice it pays. A processor payment carries an order id. A wire carries a reference the customer typed. A remittance advice arrives as a PDF in an inbox. This operator reads each of those, finds the open invoices for that customer in your ledger, and works out which ones the payment covers.

It proposes the application: these invoices, this amount each, this residual. A short pay is proposed with the residual coded to the reason you choose. A payment that matches nothing is proposed on account. Once approved, the payment is applied once and the receipt shows the remittance it was read from.

This is a reference listing. It documents what Fibric would read from Cash Application and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Open ACCREC invoices in Xero with AmountDue, and prepayments or overpayments with RemainingCredit on the same contact
  • Open invoices and unapplied payments in QuickBooks Online, NetSuite, Sage Intacct, or Business Central
  • Successful charges and their balance transactions in Stripe, with the invoice or order id in the charge's metadata
  • Adyen and PayPal payments carrying a merchant reference
  • Remittance advices arriving as attachments in a Gmail mailbox, noticed through a users.watch subscription
  • Lockbox and bank files landing on an SFTP server or in an Amazon S3 bucket, noticed on object creation
  • Customer payments already applied, so the same remittance is never read twice

Proposed actions

  • Target capability: propose applying one payment to the invoices the remittance names, with an amount per invoice
  • Target capability: propose a short pay: the invoice paid to the remitted amount and the residual coded to a deduction reason
  • Target capability: propose allocating an existing credit note or overpayment to the invoice it offsets
  • Target capability: propose an on-account payment where no invoice matches, with the candidates it rejected
  • Target capability: propose a query to the customer's accounts payable contact when a remittance names an invoice that does not exist

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Apply processor payments by order id

    Each Stripe charge is matched to the NetSuite invoice whose number sits in the charge's metadata. One approval applies the day's payments; unmatched ones are listed on account.

    With Stripe, NetSuite

  • Read the remittance from the inbox

    A remittance advice arriving in the accounts receivable Gmail mailbox is parsed for invoice numbers and amounts, then matched to Xero ACCREC invoices for approval.

    With Gmail API, Xero

  • Lockbox file to ledger

    The bank's lockbox file lands on SFTP each morning. Each line is matched to open QuickBooks Online invoices by customer and amount, with short pays coded to your deduction reasons.

    With SFTP, QuickBooks Online

  • Use the credit already on the account

    Before proposing an application, it checks Sage Intacct for open credit memos on the customer and proposes allocating them first.

    With Sage Intacct

Requirements

  • A ledger connector with open receivables and customer payments: Xero, QuickBooks Online, NetSuite, Sage Intacct, or Business Central
  • A source of payment records: Stripe, Adyen, or PayPal for processor payments, or a bank file on SFTP or Amazon S3
  • A mailbox or folder where remittance advices land: Gmail API, Amazon S3, or SFTP
  • A deduction account and reason codes for short pays, and a rule for payments below the smallest open invoice
Authentication
It holds no bank or processor credentials. Payments, remittances, and invoices are read through the ledger, processor, mailbox, and file connectors you attach.

Limits

  • It reads text from remittance PDFs and CSVs. A scanned image without a text layer is attached for a person to read.
  • A payment with no reference and a round amount is proposed on account, not guessed against an invoice.
  • Foreign-currency payments are applied in the invoice currency. Exchange differences remain a ledger posting.
  • It applies cash; it does not receive it. Deposits still come from the bank feed or the processor payout.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Cash Application ↗

Questions and answers

What do I approve for each payment?
One application per payment. You see the payment, the remittance it was read from, the invoices matched with amounts, and any residual. Change an invoice, split differently, or send it on account. Approval applies it in the ledger.
What record follows an application?
A receipt per payment: the remittance document, the invoices and amounts applied, the residual and its reason, who approved, and when. Unapplying is described on the receipt.
Does it apply cash without a person?
No. Every application waits for approval and runs once. If the ledger already shows the payment applied when approval arrives, it stops and shows you the existing application.
Ask about Cash Application

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy