Skip to content
FactorFox

Accounting

Nothing posts to your book because a machine was fairly sure.

Written for the controller and the cash application clerk. Between a payment arriving and a client’s balance being right sit a remittance advice in five formats, a short pay nobody explained, a reserve that should move, a fee that accrued yesterday, and an examiner who will ask about all of it in March.

FactorFox proposes. A person applies. The distinction sounds procedural until the first time a confident automatic posting takes a week to unwind.

Why this exists

Cash application is not data entry. It is a series of small judgements at speed.

A payment for 41,318.62 against four invoices, one of which was short paid for a reason that is on a stub somebody scanned, is a decision. Software that treats it as a match is guessing on your behalf.

A remittance arrives as a PDF in a shared mailbox, gets printed, keyed by hand, and the original ends up somewhere nobody can find in eight months.
Inbound mail is classified, its attachments preserved as evidence, and a cash application proposal is raised with the original message attached to it.
Automatic matching posts a payment against the wrong invoice because the amounts happened to agree, and the error surfaces during a collections call.
A proposal states what it matched, what it could not match, and how much is left over. A person accepts it, and their name goes on the posting.
A short pay is applied as a write off because it was small, and the pattern of small write offs against one debtor is never seen as a pattern.
A short pay raises a deduction rather than disappearing. It reduces the eligible pool, opens against the collections case, and joins that obligor's dilution history.
Month end is a week of reconstruction, because the evidence for what was done lives in mailboxes, spreadsheets and memory.
Audit packets are sealed at the point they are produced and a database trigger refuses mutation. Reconstruction is not required, because nothing was ever unrecorded.

Cash application

From a payment landing to a balance being right

Six stages. The interesting ones are the two where the platform declines to decide.

  1. Arrive

    Remittance from wherever it comes

    A shared mailbox through Microsoft Graph, an EDI 820 from a trading partner, a lockbox file, a portal upload or a scanned stub. Every door lands in the same rail and the same message is never ingested twice.

  2. Read

    Structure without losing the original

    Remittance detail is extracted under a strict schema and revalidated deterministically before it is trusted. The original stays exactly as it arrived, and the extraction is marked as a derivative of it.

  3. Propose

    A match, with its uncertainty stated

    Invoices identified, amounts allocated, remainder named. Where the platform is not sure, it says which part it is not sure about instead of choosing the most probable answer and moving on.

  4. Apply

    A person accepts, adjusts or refuses

    The posting carries their name. This is the step nobody else in this category wants to keep, and it is the one that means your ledger is never a place where machine guesses accumulate.

  5. Resolve

    What did not match becomes work, not a suspense balance

    Short pays become deductions against the collections case. Unidentified cash sits as unapplied, reduces availability rather than floating outside it, and appears on the worklist rather than in a quarterly clean up.

  6. Settle

    Fees, reserves and the client's statement

    Accrued fees are drawn, reserve movements are recorded with their own authority, and the client sees a statement that agrees with your ledger because it is generated from it.

Bank change content

One class of message is never applied, whatever it says.

The cash application mailbox is the softest target in a factoring company. It receives money information from strangers all day, it is worked at speed, and the people working it are rewarded for clearing it. A well written note from a debtor’s accounts payable department advising new remittance details fits into that flow perfectly, which is precisely why it works.

So that class of content is pulled out of the flow entirely. It is classified as requiring verification, it never reaches a party record as an edit, and the change it requests sits under a hold that only a named human can release. Automated approval is refused outright rather than disabled by default, because a setting that can be switched on is a setting that eventually gets switched on during a busy week.

The same message becomes evidence rather than an instruction. It stays attached to the party, dated, with its sender, and it is available in the fraud case if one is opened.

Classified, not processed

Mail content that looks like a bank account change is classified as requiring verification rather than applied.

It is the single most expensive email a factoring company receives, and the accounting inbox is exactly where it is addressed to arrive.

Ledger movement

The entries this business actually runs on

General ledger packages describe none of these, which is why factoring companies end up running two systems and reconciling them by hand.

Advance and reserve

A funding splits into what the client receives now and what is held back. Both sides are recorded against the schedule and the client, and the reserve balance is a position you can explain invoice by invoice.

Fee accrual

Discount and factoring fees accrue on the terms of the facility, on the days they are actually earned, rather than being computed once at settlement from a formula in someone's head.

Minimums and misc fees

Monthly minimums, wire fees, ACH fees, verification and audit charges, applied under the facility terms and visible to the client on the statement that shows them.

Reserve release

Moved when the conditions for moving it are met, recorded as a release with its own authority. Never as an adjustment that appears without an actor beside it.

Chargebacks and repurchases

An invoice that comes back does so as a recorded event against the schedule, the client and the obligor's history, not as a manual credit that severs the link to what caused it.

Unapplied and on account

Held visibly, reducing availability rather than sitting outside it, and appearing as work rather than as a balance that grows quietly between audits.

Audit packets

The examiner window

A field exam, a bank review or an annual audit asks the same underlying question in different words: show me what you did, when you did it, and what you knew at the time.

What a sealed audit packet contains and why
ContentsWhy it is in there
The figures, as of a fixed momentA packet without an as of stamp is a report. With one, it is a record, and two packets from different dates can be compared honestly.
Evidence references into recordsEvery figure points at the invoices, cash, credits, reserves and documents that produced it. The packet is a route into the book rather than a summary of it.
The policy version in forceEligibility rules, advance rates and reserve policy as they stood, so a later change cannot make a past decision look wrong or look right.
Actors and approvalsWho requested, who approved, who counter reviewed, and from which surface. Where an exception was granted, the reason they typed and when it expires.
What was not knownChecks that were unconfigured, sources awaiting a live feed, and coverage stated separately from confidence. An examiner trusts a system that reports its own blind spots far more than one that never has any.
A sealThe packet cannot be mutated. A database trigger refuses the write. A correction is a restatement that stands beside the original and names what changed.

Risk observations are append only at the database level, and the platform refuses to show a delta it cannot prove. Where there is no comparable prior observation it offers to take a first observation rather than reconstructing a plausible yesterday. That refusal is what makes the rest of the packet worth reading.

Two systems, one book

Where FactorFox stops and your general ledger starts.

FactorFox holds the operating book: schedules, advances, reserves, fees, cash, deductions, chargebacks and client statements, at the level of the individual invoice and the individual obligor. That is the layer a general ledger package was never designed to hold, and the layer where every question a factoring company actually gets asked is answered.

Your general ledger keeps doing what it does. Client receivable ledgers synchronised from QuickBooks Online or Xero arrive read only, on the client’s consent, and FactorFox never writes into a client ledger. Synced invoices still face every ingestion gate, because a connector is a submission channel and not a side door onto your book.

The practical consequence is what happens at month end. The reconciliation most operations run in a spreadsheet exists because the operating detail and the accounting summary live in two places that were never reconciled continuously. Holding the detail with its evidence, and posting only what a person accepted, removes most of the differences before anyone has to find them.

Any remaining ones have names attached. A difference you can attribute is an afternoon. A difference you cannot is the week that everybody in this industry has had at least once.

Bring us the payment nobody could apply.

The one with four invoices, two short pays and a stub in an email thread. We will show you the proposal FactorFox raises and exactly which parts it refuses to decide for you.