What it runs
Nightworks AI runs the recurring finance work a controller or CFO owns: the close, receivables, payables, tax, cash, and audit readiness. Agents prepare the work and the evidence behind it. A person signs. Nothing moves money without a person deciding.
For an operations manager, the same agents work receiving, inventory, fulfillment exceptions, and carrier records, and every exception comes back to a person.
The work
Finance and accounting
The close and intercompany balances are prepared on evidence and held for your signature; the auditor packet is planned and not yet available.
Reconciliations, accruals, and correcting entries.
Every posting states its intent, carries its evidence, and holds for a person.
Operations
Receiving, inventory, fulfillment exceptions, and carrier-record reconciliation share the same evidence and the same record.
Every workflow stays within the permissions you recorded.
Nothing publishes itself.
Customer support, marketing, sales, and other functions are available as add-ons.
Customer email under recorded limits.
Each function is a job a finance team already owns. The agent behind it prepares the work; a person decides anything that posts, files, or pays.
Bank reconciliation, intercompany balances, and close-phase order. An unsigned period stays held until a person records the decision.
B2B payouts are matched against the receivables aging. Unmatched payouts come back for review.
PO matching and vendor exceptions, receiving to invoice.
Retailer settlements and marketplace activity are checked against the records behind them. An inadequately supported settlement or deposit stays held.
Sales tax and income tax work from source records. Nothing files without a recorded human decision.
A cash forecast built from operating records, for the person who has to stand behind the cash position.
Invoice and spend review against source documents. Exceptions come back to a person.
The close packet keeps evidence, decisions, and open exceptions together. That is the record an audit package starts from.
The work an operations manager already owns, with source evidence, recorded permissions, and checks of the result.
On-hand and receiving records are checked against source. Gaps surface as exceptions, not as assumed counts.
Order, return, and fulfillment breaks stay in front of a person until they are resolved.
Carrier scans and shipment records are compared. A missing scan does not become a completed shipment.
Three worked examples
Three examples, one each from finance, operations, and customer support, follow a single exception from the first signal to the operating record. They use example data, not any customer's books. Each one stops where a person has to decide, so you can see what a hold looks like before anything is posted, shipped, or sent.
Worked example · Financial close
A close exception is reviewed and prepared for a decision. The books remain unchanged.
Illustrative only. Example data, not a customer's case or a live result.
No live connection. These examples cannot connect to your systems, collect case data, or take action. Only your accessibility preferences can be saved.
The steps illustrate how a held exception is reviewed; they are not a completed customer case.
A close exception opens the example: the records need a closer look.
The review gathers the available records and identifies gaps or disagreements.
The proposed decision sets out the evidence, alternatives, expected result, and reasons to stop.
The review is ready for a person. No posting or payment has been made.
It waits for you to approve, narrow, return, or reject the proposal. No decision has been recorded.
The proposal has not been approved, so no action has been taken.
After an approved action, the destination system must confirm what changed. This example has no live connection.
Without confirmation from the destination system, the result remains unproven.
The open item stays in the record, together with the decision still needed.
Worked example · Inventory + fulfillment
Conflicting stock records lead to a proposed routing decision that waits for a person.
Illustrative only. Example data, not a customer's case or a live result.
No live connection. These examples cannot connect to your systems, collect case data, or take action. Only your accessibility preferences can be saved.
The steps illustrate how a held exception is reviewed; they are not a completed customer case.
An inventory exception opens the example: two records disagree about availability.
The review brings the conflicting availability and routing information together.
The proposed decision compares holding, rerouting, and further review, with clear reasons to stop.
The exception is ready for review. Stock and routing remain unchanged.
It waits for you to approve, narrow, return, or reject the proposal. No decision has been recorded.
The proposal has not been approved, so no action has been taken.
After an approved action, the destination system must confirm what changed. This example has no live connection.
Without confirmation from the destination system, the result remains unproven.
The open item stays in the record, together with the decision still needed.
Add-on example: customer support.
Worked example · Customer operations
A service exception leads to a proposed resolution that waits for a person.
Illustrative only. Example data, not a customer's case or a live result.
No live connection. These examples cannot connect to your systems, collect case data, or take action. Only your accessibility preferences can be saved.
The steps illustrate how a held exception is reviewed; they are not a completed customer case.
A service exception opens the example: the request needs a decision.
The review brings the example service history and policy conflict together.
The proposed decision compares resolutions, limits, and reasons to stop.
The resolution is ready for review. No message, refund, or credit has been sent.
It waits for you to approve, narrow, return, or reject the proposal. No decision has been recorded.
The proposal has not been approved, so no action has been taken.
After an approved action, the destination system must confirm what changed. This example has no live connection.
Without confirmation from the destination system, the result remains unproven.
The open item stays in the record, together with the decision still needed.
What you see in each example
01
Follow what started the work, the evidence, the proposed decision, the prepared work, your approval, the action, confirmation from your systems, the result, and its record.
02
When your decision has not been recorded, nothing after it happens, and nothing is shown as done.
03
An outcome is claimed only when the system of record confirms the action, not when an agent reports it.
04
An unresolved exception stays in the record for the next review instead of disappearing behind a completion message.