AP and Bank Rec Desk Official

Reads the invoice, codes it from the vendor's rules, checks for duplicates and against its PO, sets the approval tier and approver, and raises an exception when something is wrong.

1. 01Invoice {{invoice_number}} from {{vendor}}, dated {{invoice_date}}, due {{due_date}}, amount {{amount}}, PO {{po_number}}, source {{source}}. Description: {{description}} A source file may be attached. If one is, READ IT BEFORE ANYTHING ELSE and report what the DOCUMENT itself says, separately from what was typed: the supplier name, the invoice number, the invoice date, the due date, any PO number printed on it, and the TOTAL DUE. Read the total from the document's own total line, not by adding the rows up yourself. If there is no file, or you cannot read it, say so plainly and work from the typed fields alone; never guess at what a document would have said. Then compare the document with what was typed, and treat the two kinds of difference differently: - MONEY. If the document's total is not the same as the typed amount, that is a discrepancy for a person to settle, NOT something to correct silently. Report both figures. Money is never overwritten on a human's behalf. - EVERYTHING ELSE. A PO number, an invoice date or a due date that differs is simply a typing slip, and the document is what the supplier sent. Take the document's version and report which field you are correcting. Read the vendor in the Vendors table (default account, class, requires PO, status). Search the Invoices table for duplicates, ignoring this invoice's own row: it is already saved in the table, so finding one row that is this invoice itself is NOT a duplicate. A duplicate means a second, different row with the same vendor and invoice number, or the same vendor, amount and a date within 7 days. If the vendor requires a PO, find the purchase order: using the PO number from the document when it gives one: and compare the amount (within 2 percent) and whether goods were received. Read the Approval Rules to find the tier, and Client Contacts to find the approver holding that role (the controller when none). Work the tier out from the DOCUMENT's total when you have one, because that is what the supplier is actually asking to be paid; otherwise use the typed amount. Output: Plain text lines: what the document says (total, invoice number, dates, PO) or that no file was supplied; whether the document's total matches the typed amount, with both figures when it does not; any non-money field you are correcting from the document; then the coding, the duplicate finding, the PO finding, the tier and the approver.
2. 02Update this invoice row in the Invoices table. Always set: Account and Class from the vendor (leave blank if the vendor is unmapped), Duplicate Check (Clear, Possible duplicate or Duplicate), PO Match (Not required, Matched, Mismatch or Missing PO), Tier and Approver. Where the document corrected a non-money field, write it: PO Number, Invoice Date, Due Date. NEVER write the Amount. The typed figure stays exactly as the person entered it, even when the document disagrees: a human settles money. Then set Status: - Exception when the checks found a duplicate, a PO mismatch, a missing PO or an unmapped vendor; - Exception ALSO when the document's total differs from the typed amount, with Exception Reason naming both figures and which is which, for example "Document total 1,880.00 does not match the amount entered, 1,450.00. Confirm which is right, correct the Amount and re-process."; - Approved when the tier auto-approves and every check is clear; - otherwise Awaiting approval. For any exception also create an Exceptions row with the kind, the invoice number, today's date and Status "Open". Set the status explicitly: an exception left without one never reaches the desk's exception queue, which lists open items only, so it exists but nobody sees it. Use kind "Amount mismatch" for a document-versus-typed difference and say in the text that it is the document disagreeing with what was entered, so it is not confused with a purchase-order mismatch. Finally write a summary, plain text, one line each: what the document said (or that there was no file), what was coded, what was checked, who approves, what needs a person. If you corrected a field from the document, say which. If money disagreed, say so and give both figures. Output: The processing summary, plain text, naming what the document said and any discrepancy or correction it produced.

Writes the exact bill entry for the ledger (vendor, date, due, account, class, memo, amount) and moves the invoice to Ready to post.

1. 01Approved invoice {{invoice_number}} from {{vendor}} ({{invoice_date}}, due {{due_date}}, {{amount}}), coded {{account}} / {{class_name}}. Memo: {{description}}. Read the vendor's ledger id and terms from the Vendors table. If Account is blank, output exactly "Cannot post: vendor unmapped" and do not change the row. Otherwise write the posting pack as plain text lines: Vendor (ledger id), Bill number, Bill date, Due date, Line 1: account, class, memo, amount, Total, Attachment to add, Terms. Then update the invoice row's Status to Ready to post. Output: The posting pack lines, or "Cannot post: vendor unmapped", as plain text.

Selects the posted invoices due by the run date for the run's method, lists them with totals, and schedules them.

1. 01Payment run "{{run}}" on {{run_date}} by {{method}}. Notes: {{notes}} Read the Invoices table for Status Posted, join each to its vendor's payment method, keep those paid by {{method}} with a due date on or before {{run_date}} (for ACH, also within 7 days after). List them: vendor, invoice number, due date, amount. Total them. Output: The invoice lines and the total, as plain text.
2. 02Update each listed invoice's Status to Scheduled. Update this run's Invoice Count and Total. Then write the run sheet for the controller: the lines, the total, and one line saying "Release in the bank, then mark the run Recorded and the invoices Paid". Plain text. Output: The run sheet as plain text.

Reads the uploaded statement (PDF or CSV), creates one Bank Transactions row per line, and reports the count and the closing balance check.

1. 01Statement "{{label}}" for {{account}}, {{period_start}} to {{period_end}}, closing balance {{statement_balance}}. Read this statement's file from the Bank Statements table (use the PDF tool for a PDF; read a CSV as text). Extract every transaction line: date, description exactly as printed, amount, direction. Do not include balance-forward or summary lines. Output: The extracted lines, one per line, as plain text.
2. 02Create one Bank Transactions row per extracted line: Line as "<date> <description> <amount>", Statement = this statement, Date, Description, Amount, Direction, Status Unmatched. Update this statement's Lines Imported and set its Status to Imported. Then report: lines imported, total debits, total credits, and whether opening plus credits minus debits equals the closing balance (say the difference if not). Plain text. Output: The import report as plain text.

Finds the bill payment, deposit or recurring payee behind a statement line, proposes a bank rule for recurring payees, and marks the line for the client when nothing explains it.

1. 01Line "{{line}}": {{date}}, {{description}}, {{amount}} {{direction}}, from statement {{statement}}. Search the Invoices table for a Scheduled or Paid invoice with this amount whose vendor name appears in the description; the Vendors table for a payee this description contains; the Bank Transactions table for the same payee matched before (a recurring payee); and the coding guide for bank rules. Decide: Matched (say to what), Needs rule (write the rule as "Description contains X and amount A to B: account, class"), Posted (bank fee or interest: say the account), or Ask client. Output: The decision and its evidence, as plain text lines.
2. 02Update this line's row: Status, Matched To (for Matched or Posted), Proposed Rule (for Needs rule). If it matched a Scheduled invoice, update that invoice's Status to Paid. Then write two lines: the decision, and what the controller should do (nothing, add the rule, post the entry, or wait for the client). Plain text. Output: The two-line result, plain text.

Turns a statement line marked Ask client into one clear question for the right contact, on the portal, with the email draft to nudge them.

1. 01Bank line "{{line}}" dated {{date}}: {{description}}, amount {{amount}}, direction {{direction}}. This line could not be explained, so the client must be asked about it. First read Client Questions and check whether an OPEN question already exists for this same transaction. If one does, stop and say so; do not write a second. Otherwise read Client Contacts and choose who to ask: the Owner for deposits and owner-looking items, the Ops Manager otherwise. Then write the question itself: one sentence giving the date, the amount and the payee, then one sentence saying exactly what you need to know. Plain language, no jargon, and never guess what the payment was for. Output: The chosen contact and the question text, or a note that an open question already exists.
2. 02If an open question already exists for this transaction, do nothing further. Otherwise create ONE row in Client Questions with: Question (the text you wrote), Transaction (this bank line), Contact (the person you chose), Asked (today) and Status "Open". Then write the nudge email for that contact: two sentences, the question, and "Answer it on your portal in one line". Plain text, no greeting or sign-off; the desk adds those. Output: The email text, and confirmation of the question row created.

Compares the statement balance to the books for the period, lists the variance items by type, and writes the notes for the close package and the lock-date reminder.

1. 01Reconciliation "{{reconciliation}}" for {{account}} to {{period_end}}: statement balance {{statement_balance}}, book balance {{book_balance}}. Read the Bank Transactions for this account and period that are not Matched or Posted, the invoices Scheduled but not Paid, and any fee or interest line not yet posted. Classify each as a variance item using the guide's checklist and total them. Say whether the difference is fully explained. Output: The variance items by type with amounts, and whether the difference is explained, as plain text.
2. 02Write the variance notes for the close package: the two balances and the difference, the items by type, what remains unexplained, and the actions (post the fee, wait for the client's answer on X, void the duplicate). Update this reconciliation's Difference and Status (Balanced if explained to zero, else Variance). End with: "When it balances, tick the reconciliation in the ledger and set the lock date to {{period_end}}". Plain text, under 250 words. Output: The variance notes as plain text.

Counts the queue by status and tier, SLA breaches, exceptions, cash going out this week and unmatched bank lines, and sends it to the controller.

1. 01Count from the tables: invoices by Status and by Tier; invoices Awaiting approval older than their tier's SLA days, by approver; open Exceptions by Kind; Payment Runs Proposed or Released this week with totals; Bank Transactions not Matched or Posted, and how many are older than 7 days; Client Questions Open; Reconciliations not Closed. Output: The counts, as plain text lines.
2. 02Write the digest: the numbers as short lines, then "Past SLA:" by approver, "Exceptions:" by kind, "Cash out this week:" the runs, "Bank:" the unmatched count and the oldest, "Waiting on the client:" the questions. Then "Decisions this week:" at most three. Under 250 words, plain text. Send it with Turtle Notify to the controller and confirm. Output: The digest text and a confirmation that it was sent, plain text.