Core Operations Standard Operating Procedure (SOP)
Document Version: 6.0
Effective Date: March 1, 2026
Department: Cross-Functional (Finance, Claims, Underwriting, Treasury, HR)
Prepared By: Central Operations & Process Excellence Team Document Owner: Central Operations & Process Excellence Team
Approved By: Sarah Jenkins, VP of Core Operations
Supersedes: Version 5.0
Support Contact: support@vanguardshield.com | 1-800-555-0199
This SOP establishes standardized operational procedures for designated staff within Vanguard Shield Mutual. This document is intended for trained personnel with approved access and required confidentiality, security, and role-based training.
This SOP does not replace legal, regulatory, compliance, or company policy requirements. If this SOP conflicts with applicable law, regulation, contractual obligation, or company policy, the stricter requirement governs. Questions or uncertainty must be escalated to the applicable manager or Compliance before action is taken.
This manual provides foundational procedures for junior-level analysts and operational staff at Vanguard Shield Mutual. It covers selected daily, weekly, monthly, and quarterly tasks across accounting, treasury, underwriting, claims, accounts receivable, payroll, and employee expense review.
All steps in this SOP must be performed using only the following tools. Do not reference or rely on any software, service, or data source other than those listed in section 1.2 unless this document is formally amended.
Slack — workspace VanguardShield (channels, DMs, search, profiles)
Shopify — Orders tab for internal marketing / merch verification
Jira — Vanguard Ops Project Space (issues, attachments, comments, transitions, queues) •
Excel — workbooks (.xlsx) opened locally from Jira attachments or Email attachments • Word
memos and letters (.docx); export to PDF when a PDF deliverable is required • PowerPoint
presentations (.pptx) when a slide deliverable is specified
PDF — review of supplied PDF attachments; Word may save as PDF for outbound documents
Source data (reports, exports, clearing confirmations, policy PDFs, claim packets, etc.) is assumed to arrive as attachments on the Jira issues or Email threads cited in each procedure, or as files you save to Excel/Word from those attachments. If an expected attachment is missing, follow the exception path (typically Jira escalation) for that section.
If you lack access to any required tool, create a Jira ticket in the IT-Support queue immediately.
Unless a procedure names a different field, the following standard custom-field names apply across all Jira projects referenced in this SOP. If a required field is blank or missing on a particular issue, follow the fallback path noted for that field.
Reporting Manager: Custom field on HR, T&E, and expense issues containing the Jira username of the employee’s direct manager. Fallback: Email people@vanguardshield.com with the employee’s full name to request their reporting manager. If the People directory does not return a result, create a Jira ticket in the HR-Ops queue using Template B-8 (§Appendix B).
Department Head: Custom field on OPS-FIN-BVA-* (budget-variance) issues containing the name of the department’s budget owner. Fallback: search the BVA issue description for “Budget Owner;” if not present, Email finance.ops@vanguardshield.com citing the BVA issue key and requesting the department head name. Note the substitution in your memo.
Billing Contact Email: Field in the issue description on OPS-AR-CLIENT-* issues holding the client’s invoicing email address. If blank, Slack #ar-collections using Template B-5 to request the contact before proceeding.
Rate Table Source: Field in the issue description on OPS-UW-POL-* issues that must reference the canonical rate-table Jira issue key and file name. Procedures referencing this field are in §5.1.
Queue Assignee (role-based routing): Several procedures route Jira tickets to a named role (e.g., “Senior Accountant,” “Finance Controller,” “Chief Compliance Officer”). The current individual filling each role is maintained in the pinned issue description on that queue’s Jira board. Open the target queue board, read the pinned issue titled Queue Roles & Assignees, and assign to the username listed for the role. If the pinned issue is missing or the role is blank, create a Jira ticket in IT-Support titled Missing Queue Assignee – [Queue Name] – [Role] and Slack #ops support with the same details.
Materiality Override (reconciliation thresholds): Where a reconciliation procedure permits a de
minimis tolerance before requiring a variance workbook or exception ticket, the threshold is stated in that procedure’s reconciliation step. If no tolerance is stated, exact matching is required and any
difference must be documented. If a queue’s pinned issue (Queue Roles & Assignees) includes a “Materiality Override” section with a different dollar threshold for a specific procedure, the
Jira-posted threshold governs over the threshold printed in this SOP, provided the posted threshold
is equal to or stricter (lower) than the SOP default. A posted threshold that is less strict (higher) than the SOP default requires a formal SOP amendment per Document Control & Governance. This
allows Finance or HR leadership to tighten thresholds without a full SOP revision while preserving
the Document Control principle that the stricter requirement governs.
Underwriting intake (UW data requests): Email underwriting.ops@vanguardshield.com when a procedure requires payroll or underwriting application data by email after Jira comment and @mention paths are exhausted (see §5.2).
OPS-HR-TE workflow (Sales T&E): Use the Approve, Reject, and related transition names documented on the HR-Expense or OPS-HR-TE queue board pinned issue Workflow & Transitions (Jira is the system of record; labels may differ by scheme).
UW data Slack (optional notice, keys only): Use #uw-data-requests unless the underwriting queue pinned issue names a different channel.
All output files produced under this SOP must follow the naming pattern stated in the procedure that creates them. Where a procedure does not specify a file name, use the default convention:
Examples: DemandLetter_[ClientID][YYYY-MM-DD].pdf, SUI_Variance[Quarter]_[YYYY-MM-DD].xlsx. Do not use spaces in file names; use underscores.
Objective: Clear and properly document Intercompany Suspense activity by the 5th business day of each month.
Generate workbook: On Jira issue OPS-FIN-SUSPENSE-[YYYY-MM] (month-close package), download the suspense workbook attachment (Excel) and save a local working copy with a clear month identifier (§1.4).
Filter discrepancies: In Excel, filter the Amount column into (a) items exceeding $5,000 and (b) items less than or equal to $5,000.
Clear items ≤ $5,000: For each line, (a) open the linked Jira sub-task or the PDF attachment on the month-close issue whose name or description matches the transaction ID and amount; (b) confirm GL coding from the invoice text and the line description in Excel; (c) document the tie-out in your local suspense workbook (add the following columns if not already present: Support Found (Y/N), Support Location / Invoice #, and Reviewed By); (d) if support is found, record the reclassification in Jira: comment on the line’s sub-task with transaction ID, target GL, and status FIN-100 Cleared & Posted. If support cannot be found or coding is unclear, go to Exception handling.
Conflicting GL codes: If the GL code on the PDF invoice disagrees with the GL code in the Excel line description, do not resolve the conflict yourself. Record both codes in the your local suspense workbook tie-out columns (add a column “Conflict?” marked Y). Create a comment on the Jira sub-task: “GL conflict: Invoice shows [code A], Excel line shows [code B] — requesting Controller clarification.” Then follow the Exception handling step below.
Verify approval evidence (items > $5,000 only): In Slack, open #finance-approvals. Search: has:link [Exact Dollar Amount] to locate the manager approval message.
Locate receipts: From Jira, open the PDF invoice attached to the matching sub-task or linked
issue for that transaction ID.
Objective: Monitor departmental spending against approved quarterly budgets and identify material variances requiring explanation.
Data pull: From Jira issue OPS-FIN-BVA-[Department]-[Quarter], download the budget-vs-actual export attached to the issue (Excel as provided).
Flag overspend: In Excel, add a column for percentage variance using (Actual − Budget) ÷ Budget. If Budget is in column B and Actual is in column C, use =(C2-B2)/B2 formatted as Percentage. If Budget = 0, use =IF(B2=0,IF(C2>0,9999,0),(C2-B2)/B2) formatted as Percentage. Interpretation: 9999% means actual spend with a $0 budget and must be reviewed. Filter Variance % to show values greater than 10% (includes 9999% rows).
Investigate cause: In Email, open the shared mailbox finance.ops@vanguardshield.com. Search using the over-budget line item name and variants (vendor, project, cost center) across at least the prior 90 days. Capture search terms used and whether results were found.
Document finding: In Word, paste Memo Template D-1. Complete fields from the Budget vs. Actual workbook and any supporting emails. For the Department Head Name field in the memo, read the “Department Head” custom field on the OPS-FIN-BVA issue (see §1.3 for the field name and fallback path). If no justification email exists, do not infer a reason; state that no supporting justification was found, document search terms and date range, and proceed to escalation. If a justification email is found, complete Memo Template D-1 with the supporting details, attach the finished memo to the original OPS-FIN-BVA Jira issue, and mark the variance as Supported in the Budget vs. Actual workbook; do not escalate to FIN-Exceptions.
Escalate unsupported variance: Create a Jira ticket in FIN-Exceptions titled Unsupported Expense Variance – [Department] – Q[Number] – [Line Item]. Attach the drafted Memo D-1 and the budget-vs-actual export from the BVA issue. Paste Template B-6 into the description (it duplicates and extends the field list below for grading consistency). Also include in the description: (a) line item name, (b) budget, actual, variance %, (c) mailbox searched, (d) exact search terms and date range, (e) Controller disposition request. Assign to the Finance Controller per §1.3 Queue Assignee unless otherwise directed by your manager.
File workpaper: Save the Word memo per §1.4 (include department and quarter in the filename). Attach it to the same Jira issue (or FIN-Exceptions ticket). If applicable, put the Jira key in the file name or memo header (e.g., Jira: FIN-EXC-####).
Objective: Ensure qualifying asset purchases are capitalized and depreciated in accordance with company policy.
attachment (Excel). Filter Transaction Amount for values ≥ $10,000.
Check capitalization status: Cross-reference transaction IDs against the fixed-asset subledger attachment (Excel) from the same Jira package.
Verify depreciation method: For rows marked as Fixed Asset, compare Asset Class to the Vanguard Depreciation Matrix: IT Equipment = 3 years straight-line; Furniture = 7 years MACRS; Software = 5 years straight-line.
If method is wrong or asset class missing from matrix: Do not edit source ledgers yourself. Create or update a Jira ticket in FIN-FA-Review: (a) if class is in the matrix but life/method wrong, request change citing matrix line; attach Excel excerpt and any PDF invoice from Jira; assign to the Senior Accountant listed on the FIN-FA-Review board’s pinned issue per §1.3 Queue Assignee. (b) If class is not in the matrix, request review with proposed life blank or TBD—Policy Needed; assign to the same Senior Accountant.
Prepare adjustment (capitalization only when qualified): For items ≥ $10,000 missing from the subledger, do not capitalize on dollar value alone. Confirm qualification using invoice/PO text in Jira PDF attachments and descriptions in Excel: nature (tangible or qualifying software, not routine services), useful life > 12 months, company ownership/control, threshold met and not excluded (training, support, professional services). Capitalization guidance: items such as computers, servers, vehicles, furniture, machinery, and licensed software with a perpetual or multi-year term generally qualify (useful life > 12 months). Items such as consulting fees, temporary-labor hours, consumable supplies, maintenance agreements billed monthly, and SaaS subscriptions billed annually without a perpetual license are routine services and do not qualify. If the invoice description does not make the category obvious, treat the item as unclear and escalate per the instructions below. If qualified, create Jira OPS-FIN-JE draft with comment listing invoice/PO, vendor, description, proposed asset class; assign to the Senior Accountant per the FIN-FA-Review board’s pinned issue. If clearly not a qualifying asset, document conclusion in Excel notes and continue. If unclear, Jira comment to the Senior Accountant: Capitalization eligibility unclear—policy confirmation needed.
Objective: Provide a leadership-ready summary after intercompany suspense month-end work.
When: After completing §2.1 for the calendar month (or when OPS-FIN-MONTH-[YYYY-MM] is marked complete per that issue).
Build deck: Create the finance month-summary PowerPoint for the period (name per §1.4; include year-month in the filename). Slides required: (1) Title — Vanguard Shield | Finance
month-end | [Month YYYY]; analyst name. (2) Suspense — lines cleared to FIN-100 (count),
open exceptions (count), up to five Jira keys only (omit dollar amounts unless the parent issue explicitly allows). (3) Exceptions — remaining FIN-Exceptions keys and stated next action.
File: Attach that month-summary deck to Jira OPS-FIN-MONTH-[YYYY-MM] (or the month-close parent named on that issue).
Objective: Ensure Vanguard Shield maintains adequate liquid cash to cover daily outflows.
Preflight (data package): By 8:30 AM ET, open Jira OPS-TRE-LIQUIDITY-[YYYY-MM-DD]. Confirm the issue description states the reporting date and that the daily liquid position attachment (PDF or Excel) is present for that date. If the attachment is missing, mis-dated, or unreadable, comment on the same issue with the Data package incomplete—cannot certify liquidity review and create or reopen Jira OPS-FIN-DATA-[date] per the routing note in the OPS TRE-LIQUIDITY description. Do not estimate a balance from prior days.
Record snapshot: Download the liquid position attachment. Capture Current Liquid Balance. Add a Jira comment on OPS-TRE-LIQUIDITY with: (a) time of review (ET), (b) balance, (c) attachment name/version used, (d) your initials.
Threshold test: If Current Liquid Balance is greater than or equal to $15,000,000, comment No liquidity transfer required—meets threshold and stop for that day.
Calculate transfer amount: If below $15,000,000, compute TransferAmount = $15,000,000 − Current Liquid Balance. Follow rounding rules stated on OPS-TRE-LIQUIDITY (if none, round to the nearest $1,000). Record the arithmetic (balance read, subtraction, and rounded result) for inclusion in the TRE-Investments issue created in the Route for approval step below.
De-duplicate requests: Search Jira project TRE-Investments for open issues titled Daily Liquidity Transfer - [same calendar date]. If one already exists in Awaiting Treasury Director Approval with the same calculated amount, comment Duplicate liquidity request detected—see [KEY] instead of creating a second ticket. If an open ticket exists with a different amount, comment Amount superseded—recalculated to $[new] with brief rationale before proceeding.
Route for approval: Create or update Jira TRE-Investments issue titled Daily Liquidity Transfer - [Date]. Paste Template B-7 into the description, then add the arithmetic recorded above (balance read, subtraction, and rounded result) into the description or as an attached one-line Excel screenshot. Set status to Awaiting Treasury Director Approval. B-7 captures OPS-TRE LIQUIDITY key, balance read, TransferAmount, fund instruction, and snapshot link.
Blocked / stale path: If the TRE-Investments issue is rejected or remains in Awaiting Treasury Director Approval for more than one full business day after submission, comment on OPS-TRE LIQUIDITY-[date] with the blocking TRE-Investments key and create Jira TRE-Exceptions titled Liquidity Transfer Blocked – [Date]; assign per the Treasury escalation roster in the OPS-TRE LIQUIDITY issue description. If the roster section of that issue description is blank or missing, look up the assignee on the TRE-Exceptions board’s pinned issue per §1.3 Queue Assignee.
Objective: Investigate vendor-reported nonreceipt of payments.
Investigate payment status: Open Jira issue OPS-AP-INV-[InvoiceNumber]. Read Payment Status and ACH Trace Number fields in the description or custom fields. If status is Paid, copy the 12-digit ACH trace number. If status is not Paid (Pending, Processing, Approved-Unpaid, Under Review): (a) do not request a trace yet, (b) capture status and payment run/date from the Jira description and record them in a Jira comment on the issue (e.g., “Status: [status]; scheduled payment run: [date]”), (c) Email the vendor using Template A-4 without attaching a clearing confirmation, (d) if the vendor disputes urgency or invoice is past due, Email the AP Lead listed on the AP queue board’s pinned issue per §1.3. If status is failed/rejected, set Jira label or comment FIN-201 Vendor AP Hold and send Template A-2.
Trace funds (Paid status only—skip this step if payment status is not Paid): Download the bank trace result PDF from Jira OPS-AP-TRACE-[TraceNumber] (or use the trace attachment on the invoice issue if OPS-AP-TRACE is not used). Interpret the PDF as follows: (1) Cleared / successful — status text or code indicates completion (e.g., Posted, Completed, Settled,
Success, ACK, or equivalent) and does not show a return or reject code; (2) Rejected / failed — status shows Rejected, Failed, Returned, Unpaid, or an ACH return code (e.g., R01–R33) or bank “beneficiary reject” language; (3) Pending / inconclusive — status is Processing, Pending, or ambiguous: add Jira comment Trace inconclusive—[quote field names/values] on OPS-AP-INV and do not send Template A-1; escalate per AP queue pinned instructions. Proceed to the branch below based on (1) or (2) only when certain.
If payment cleared: Download the clearing confirmation PDF from Jira OPS-AP-INV[InvoiceNumber] first (primary location). If it is not attached there, download it from OPS-AP TRACE-[TraceNumber]. If neither issue contains the file, comment Clearing confirmation missing on OPS-AP-INV and follow the AP queue’s exception path—do not send Template A-1 until the PDF is attached. Email the vendor Template A-1 attaching the PDF.
If payment rejected: Comment on OPS-AP-INV with trace outcome summary (field/value from trace PDF). Update Jira OPS-AP-INV with FIN-201 Vendor AP Hold. Email the vendor Template A-2.
Objective: Detect international wire transfers lacking required dual authorization.
Pull population: From Jira OPS-TRE-WIRES-[Quarter], download the international wires population workbook attached to the issue (Excel as provided).
Verify authorization: For each Wire ID, open Slack and search #treasury-wires in this order until you locate the approval thread (document which query worked in your Excel wire log or Jira OPS TRE-WIRE comment): (1) has:link [Wire ID] — same pattern family as §2.1 finance approvals, for threads where the wire ID appears in a linked URL; (2) in:#treasury-wires [Wire ID]; (3) in:#treasury-wires "[Wire ID]" (quoted exact match). If all three return no results, record Slack search exhausted for that Wire ID and proceed to Escalation (missing dual approval). When documenting for Compliance (Template B-3), copy the same query order and outcome into the Slack evidence line.
Check signatories: Confirm two distinct Approved messages from users whose Slack profile Title shows VP, AVP, SVP, EVP, C-level, or higher. Record approver names, exact Approved text, and titles in Excel or in a Jira comment on OPS-TRE-WIRE-[WireID].
Escalation (missing dual approval): Update Jira OPS-TRE-WIRE-[WireID] with exception code TRE-900 High-Risk Exception (Appendix C). Create Jira Compliance-Alerts with title Exception Report: International Wire Control Exception – [Wire ID]. Paste Template B-3 into the description; attach your Excel wire row or export. Assign to the Chief Compliance Officer listed on the Compliance-Alerts board’s pinned issue per §1.3 Queue Assignee. Immediately after the Compliance-Alerts issue is created, send Slack Template B-4 to #compliance-urgent with the new Compliance-Alerts issue key only—do not post wire amounts or bank details in Slack; reference Jira only.
Happy path: Update Jira OPS-TRE-WIRE-[WireID] to Verified (or equivalent) when dual approval is confirmed. No Compliance ticket required.
Objective: Support accurate 1099 reporting by maintaining complete and valid vendor tax documentation.
Check payment threshold: From Jira OPS-AP-1099-[Year], download the year-to-date vendor disbursements spreadsheet attached to the issue. Filter YTD Total > $600.
Validate W-9: For each vendor over threshold, open Jira OPS-VND-[VendorID] and confirm a W 9 PDF is attached and current.
Apply hold if required: If no W-9 PDF on the Jira vendor record, add comment and label FIN 201 Vendor AP Hold on the active payables issue for that vendor.
Notify vendor: Email Template A-3 from compliance@vanguardshield.com. Do not remove the hold until a signed W-9 PDF is received; attach the PDF to Jira OPS-VND-[VendorID].
Objective: Mitigate bad debt through timely collections review.
Pull aging report: From Jira OPS-AR-AGING-[date], download the AR aging export attached to the issue (Excel as provided). Filter Days Overdue > 90.
Check communications: For each flagged Client ID, Slack #ar-collections — search has:link [Client ID] or the Client ID text per workspace practice. Confirm whether a payment plan is noted.
Issue demand letter: If no payment plan, Word — paste Template D-3. Fill Client ID and Amount. Export to PDF per §1.4 (include client ID and date in the filename).
Send communication: From Jira OPS-AR-CLIENT-[ClientID], read the Billing Contact Email field in the issue description (see §1.3 for field name and fallback). Email the PDF demand letter to that address. If no billing contact is listed, Slack #ar-collections using Template B-5 with Client ID only; do not send the letter until contact is provided.
Update status: Comment on Jira OPS-AR-CLIENT-[ClientID]: account status Demand Letter Sent (document date, letter filename, and billing contact used). If no response is received within the timeframe stated in the demand letter (Template D-3), update the comment to Collections Hold and note the date the hold took effect.
Objective: Reconcile estimated premium basis data with actual exposure at policy end.
Gather source documents: From Jira OPS-UW-POL-[PolicyNumber], download the policy’s estimated-exposure and actual-exposure attachments (PDF or Excel as provided on the issue— use the filenames or labels listed in the issue description).
Canonical rate file: From Jira OPS-UW-RATETABLES-[YYYY] (or the master rate-table issue named in §1.3 / the policy issue), download the current underwriting rate workbook attachment. That master issue is the system of record—do not use desktop copies, ad-hoc Email attachments, or unlinked files.
Version pin: On OPS-UW-POL-[PolicyNumber], read the Rate Table Source field (see §1.3). It must reference the same master rate-table issue key and attachment name as the file you downloaded. If missing, comment Rate table version not pinned—using master per SOP and proceed; if it references a different key or revision date than the attachment you used, stop and create Jira UW-Exceptions Rate Table Mismatch – [PolicyNumber].
Calculate actual premium: Using the downloaded master workbook only, enter payroll figures from the actual-exposure attachment for each classification code to compute audited premium.
Update audit record: Enter the calculated audited premium in the designated audit workpaper attached to OPS-UW-POL-[PolicyNumber] (create or update the workbook template linked from the issue if empty). Add a Jira comment: Audited Premium: $[Amount] | Basis: [Classification codes used] | Variance from estimated: [+/−%]. If the issue has an Audited Premium custom field, populate it.
Issue final statement: When the Jira issue status is Audit Complete (required fields and audit workpaper attached per the issue checklist), use the Generate Audit Statement workflow transition on the issue. If the transition is missing, confirm: (a) the audit workpaper is attached, (b) the Audited Premium field is populated, and (c) status is Audit Complete. If all are met but the transition is still absent, create Jira IT-Support referencing the policy issue key. If the resulting status shows UND-304 Audit Variance, treat as expected for material differences.
Objective: Prepare state exposure and tax allocation support for multi-state operations.
Step 1. Review application: From Jira OPS-UW-APP-[ApplicationID], download the locations / schedule attachment(s) listed on the issue. Note multiple states if present.
Step 2. Determine surtaxes: From the same Jira issue (or linked underwriting reference issue named in the description), download the state tax / surtax matrix attachment. Cross-reference states from the schedule.
Request missing payroll (if needed): If total payroll is not on OPS-UW-APP-[ApplicationID] or on a linked policy issue named in the description, add a Jira comment on OPS-UW-APP-[ApplicationID]: Payroll attachment required for multi-state tax allocation — see OPS-UW-TAX-[ApplicationID]. @mention the Assignee or Underwriter field on that issue. If both are blank, Email the Underwriting intake mailbox (§1.3) with subject UW-Data—Payroll for OPS-UW-APP-[ApplicationID] and both Jira keys in the body. Optional same-day notice: Slack per UW data Slack in §1.3 with only the two Jira keys—no dollar amounts. Do not continue to the calculation step until payroll is provided via Jira attachment or comment.
Step 3. Calculate allocation and surtax: In Excel, enter total payroll from the attachment (or underwriter reply) on the issue. Allocate by state: (a) if schedule shows payroll by state, State % = State Payroll ÷ Total Payroll; (b) if only locations, State % = (# locations in state ÷ total locations). Note the basis in a cell. For each state: Allocated Payroll = Total Payroll × State %; State Surtax = Allocated Payroll × rate from matrix (e.g., 1.25% as 0.0125). The next step uses surtax dollars.
Objective: Ensure tax remittances align with internal payroll liability records.
Gather reports: From Jira OPS-HR-PAYROLL-[Quarter], download the vendor tax filing PDF and the internal tax liability file (CSV) listed as attachments on the issue.
Reconcile totals: In Excel, compare total SUI on the vendor PDF to the CSV. A jurisdiction-level dollar variance of $50.00 or less (absolute value) is treated as immaterial and does not require a
variance workbook; note “immaterial rounding variance — [$X.XX]” in a Jira comment on OPS HR-PAYROLL-[Quarter] and proceed to the next jurisdiction. Variances exceeding $50.00 require documentation per the next step. Note: if the OPS-HR-PAYROLL issue description or the HR Payroll queue’s pinned issue contains a Materiality Override with a different dollar threshold, use that threshold instead (see Materiality Override under §1.3).
Document variances: If any jurisdiction exceeds the materiality threshold, create a quarterly SUI variance workbook with worksheet Variance; row 1 headers: Jurisdiction | Vendor SUI (PDF) |
Internal SUI (CSV) | Dollar Variance (Internal − Vendor) | Variance % (if Vendor > 0) | Notes; one row per jurisdiction that exceeded the threshold; Total row; Notes cite source attachment names. Save using the FIN-Exceptions or HR-Payroll naming convention on the issue, or per §1.4.
Route for action: Email the completed variance workbook to payroll.ops@vanguardshield.com with subject Quarterly SUI Variance Identified. Attach or link the Jira OPS-HR-PAYROLL key in the email body.
Objective: Ensure employee expenses are business-related and adequately documented.
Step 1. Review submissions: Open Jira OPS-HR-TE-[ReportID] for each Pending Approval expense report from Sales (details in issue description: line items, amounts, merchant).
Step 2. Cross-reference business activity: From OPS-HR-TE, classify each line as (A) meal, travel, lodging, mileage, or client entertainment (non-merchandise), or (B) Marketing Promo or
Client Gifts (merchandise). For (A) only, note weekday vs weekend/holiday, open Calendar, and confirm a meeting, client event, or business travel that covers the expense (including multi-day
windows). If (A) and no matching calendar event, treat as missing justification and go to Step 4. For (B), do not require a Calendar event—skip Calendar for that line and go to Step 3 (Shopify) only.
Step 3. Verify merch purchases: For each line you classified as merchandise (B) in Step 2 (Marketing Promo or Client Gifts), open Shopify Orders tab; search employee name to confirm order through approved internal store.
Step 4. Take action: Comment on Jira OPS-HR-TE with rejection reason and set workflow to rejected when: (a) a non-merchandise line (per Step 2) has no matching Calendar event, (b) a non-merchandise line falls on a weekend/holiday without business calendar context, or (c) a merchandise line (Marketing Promo or Client Gifts) is not found in Shopify per Step 3. Standard note text: Missing business justification/unauthorized vendor. Please submit personal reimbursement.
Notify manager (rejections only): When you applied the Take action step and set the expense report workflow to rejected for any qualifying line, send a Slack DM using Template B-2. Manager identity: read the Reporting Manager custom field on Jira OPS-HR-TE-[ReportID] (see §1.3 for field conventions and the fallback path if the field is blank). If the People directory also returns no result, create Jira HR-Ops Manager Lookup Needed – T&E Exception – [Employee Name/ID] and paste Template B-8 into the description (include OPS-HR-TE key); or Slack #hr-ops-help with the same fields as B-8 in one message; or Email hrops@vanguardshield.com with subject Manager Lookup Needed – T&E Exception – [Employee Name/ID] and body text from Template B-8. Do not send Template B-2 until the manager is confirmed.
Step 5. Approve valid reports (happy path): When no line met the rejection tests in the Take
action step (all non-merchandise lines have supporting Calendar coverage; all merchandise lines passed Shopify in Step 3), add Jira comment T&E review complete—all lines supported | OPS
HR-TE-[ReportID]. Transition the workflow from Pending Approval to Approved using the transition names under OPS-HR-TE workflow (Sales T&E) in §1.3. Do not send Template B-2.
Objective: Identify closed, paid (indemnity issued) claims where a police report suggests third-party liability. Subrogation recovery generally follows payment to the insured; unpaid closures are out of scope for this triage queue.
Step 1. Build population: Run the saved Jira filter CLM-Subro-Triage (or equivalent) limited to Status = Closed-With-Payment (or your closed-and-indemnity-paid terminal status). Optionally export issue keys to a local Excel batching list (name per §1.4) for batching. Work issues in ascending claim number unless the filter description specifies a different priority.
Step 2. Police report gate: For each CLM-[number], confirm a police report PDF is attached (issue checklist or labels—common filenames include “Police_Report”). If missing or unreadable, comment Subro triage skipped—police report PDF missing and skip; do not infer fault from other documents.
Step 3. Open and index PDF: Download that police report PDF. Note agency, report number, and report date from the header in a Jira triage comment.
Step 4. Read narrative and parties: Identify named drivers, unit numbers, and which party represents our insured (policyholder or listed driver). Skim for collision type, signals, and any statement of fault.
Step 5. Positive indicators (third party): Flag subrogation potential only when the narrative or supplemental sections attribute fault to another party using at least one of: the exact phrases Citation Issued, At Fault, or Failed to Yield directed at a non-insured party; or equivalent
standardized wording permitted by the rubric linked from CLM-Subro-Triage. If equivalents are unclear, follow Ambiguous or shared fault below—do not treat the report as meeting Positive indicators.
Step 6. Negative indicators (no flag): Do not flag if the report shows our insured was cited, labeled At Fault, Failed to Yield (insured), or the narrative indicates sole insured negligence. Comment Subro triage—no third-party fault language.
Step 7. Ambiguous or shared fault: If fault is shared, unclear, or heavily redacted, comment Subro triage—ambiguous fault narrative; supervisor review. Create Jira CLM-SUBRO-REVIEW linked to CLM-[number]. Assign to the on-call Claims Supervisor listed in the CLM-Subro-Triage filter description (look for the “On-Call Supervisor” line; it is updated weekly by the Claims desk lead). If the filter description does not contain a current on-call name, Slack #claims-ops with: “[Subro Triage] Ambiguous fault — CLM-[number] — need on-call supervisor assignment.” Do not apply CLM-440 until cleared.
Step 8. Queue transfer (positive): When Positive indicators (third party) are satisfied and neither Negative indicators (no flag) nor Ambiguous or shared fault applies, comment Subro potential: [brief quote or section/page reference]. Transition Assign to Subrogation or label CLM 440 Subro Potential per workflow.
Objective: Support accurate claim determination and payment allocation.
mismatch: do not allocate; set status CLM-910 Identity Verification Hold; add note with document reference; transition Route to Claims Supervisor (CLM-Identity). Continue to Step 3 only to flag conflicts—no payout steps until supervisor clears hold.
Review beneficiary schedule: Download the original policy (or declarations) PDF attached to the issue; note Primary and Contingent percentage splits.
Flag conflicts: Review Jira comments and PDF attachments for divorce decrees (finalized prior to the insured's date of death), competing claims, court orders, attorney letters. If CLM-910 active, do not set CLM-920; add note re potential conflict and tag the comment “Pending CLM-920 review after CLM-910 clearance.” When the supervisor subsequently clears CLM-910, return to this step: if the potential-conflict note still applies, set CLM-920 Complex Beneficiary Hold and transition to CLM-Legal per the instructions below. If identity cleared and conflict exists: set CLM-920 Complex Beneficiary Hold; note file name and date; transition to CLM-Legal (the queue is assigned to the Legal Claims lead listed on the CLM-Legal board’s pinned issue per §1.3 Queue Assignee); stop.
Calculate allocation: If CLM-910 Identity Verification Hold is still active, stop here—do not calculate allocation or route for payout; wait for supervisor clearance before returning to this step. If CLM-920 Complex Beneficiary Hold is active for any reason (including survival ambiguity in the template below), stop here—do not calculate payout amounts or transition to AP; wait for CLM Legal to clear CLM-920. If CLM-910 has been cleared, CLM-920 is not active, and Step 3 found no conflicts, read Death Benefit / Face Amount from the original policy PDF attachment; compute each beneficiary share. Record the allocation in a Jira comment on CLM-LIFE-[number] using the following structured format:
--- Beneficiary Allocation ---
Policy: [PolicyNumber] | Face Amount: $[Amount]
B eneficiary 1: [Full Name] | Designation: Primary | Split: [X]% | Amount:
$[Calculated] Beneficiary 2: [Full Name] | Designation: Primary | Split: [Y]% |
Amount: $[Calculated]
(Repeat for each beneficiary. List Contingent beneficiaries only if no Primary beneficiaries survive. To determine survival status: check Jira attachments for death certificates or court declarations naming a primary beneficiary. If none exist, assume primaries survive. If a primary beneficiary is confirmed deceased (death certificate attached), exclude them and redistribute their share pro rata
among surviving primaries (new % = original % ÷ sum of surviving primaries' original %). If survival is ambiguous, set CLM-920 Complex Beneficiary Hold, route to CLM-Legal per Step 3, and STOP?do not finish this allocation block or transition to AP for payout.)
Analyst: [Initials] | Date: [YYYY-MM-DD]
Route to AP for payout only when CLM-910 and CLM-920 are not active, the structured allocation comment is complete, and you did not stop for ambiguous survival above. Then transition the issue to Route to AP for Payout with the allocation comment in place.
Objective: Identify claim anomalies requiring SIU review.
Step 1. Triage intake: Open Jira CLM-PROP-[number] from the SIU prep queue or supervisor assignment. Read loss type, date of loss, and any prior-claim flags in the description. If status is already CLM-999, confirm whether you are documenting supplemental findings only.
Step 2. Photo inventory: Download current-loss images from Jira attachments. Current-loss images are defined as files with image extensions (.jpg, .jpeg, .png, .gif, .tiff) whose Jira attachment label or file name includes the reported date of loss or contains the word “current,” “loss,” or “scene.” Exclude PDF documents, spreadsheets, and any image file whose name or
label references a prior claim number (those are used in the historical comparison in Step 3). Comment Photo inventory complete—[n] image files with the list of file names included in the comment.
Step 3. Historical comparison: Use the historical photo package linked from the claim issue (ZIP or prior CLM attachments). Identical match (binary): same file as a prior attachment (matching file name and size, or checksum if provided in Jira), or documentation in Jira explicitly states the file is a re-upload from a prior claim. Same-angle match (stricter—use only when all are true; otherwise do not use this label): (i) prior and current issues share the same loss location address in Jira; (ii) the same architectural feature or vehicle body panel clearly occupies the majority of both frames (same wall face, same bumper corner, etc.—not merely “both show water damage”); (iii) at least two fixed reference points (e.g., two corners of one window, or plate + same body line) appear in the same left-to-right order and within 15% of frame width of each other’s positions. If you cannot verify (ii) and (iii) without guesswork, do not call it a same-angle match—comment Possible visual similarity—needs manual review and do not rely on that alone for Step 6 unless an identical match exists or Step 5 hits. Document confirmed pairs as Current [file] matches Prior CLM-[id] [file/date] — [Identical | Same-angle per criteria] in Jira.
Step 4. Metadata sanity check: If visible timestamps or embedded file dates contradict the reported date of loss, note Date metadata inconsistency in an internal Jira comment (no accusatory language in customer-visible fields).
Step 5. Inspector notes: Download the field inspector notes PDF from the claim issue attachments (filename often includes “inspector” or “field”). Search for Inconsistent, Pre-existing, Wear and tear, Prior damage, Unrelated. Copy exact wording into an internal Jira comment (SIU prep—inspector quotes).
Step 6. Decision matrix: Apply SIU hold and referral below if (a) an Identical match or a confirmed Same-angle match (per the criteria in Historical comparison, Step 3) is documented, OR (b) Inspector notes contain any keyword hit from that step, OR (c) Metadata sanity check shows a date inconsistency that undermines loss timing. If none apply, comment SIU prep—no automated SIU triggers; resume standard handling.
Step 7. SIU hold: When the Decision matrix above applies, set CLM-999 SIU Hold. Do not discuss fraud theories with the insured in the same thread as SIU comments.
Step 8. Refer to SIU: Word — Memo Template D-2; save the referral memo per §1.4 (include claim number in the filename); attach to Jira SIU-INTAKE-[ClaimNumber]. On CLM-[number], comment only SIU referral filed—see SIU-[key].
All external emails must be sent from an authorized @vanguardshield.com account. Templates below ordered A-1 through A-4.
Subject: Vanguard Shield Mutual - Payment Confirmation - Invoice #[Invoice Number]
Dear [Vendor Representative],
Thank you for contacting us regarding Invoice #[Invoice Number]. According to our Accounts Payable records, this payment was successfully processed and cleared.
Payment Details:
Amount: $[Amount]
Date Cleared: [Date]
ACH Trace Number: [Trace Number]
Attached is the PDF payment confirmation for your records. If you need further assistance, please let us know.
Best regards,
Finance Operations | Vanguard Shield Mutual | support@vanguardshield.com | 1-800-555-0199
Subject: Vanguard Shield Mutual - Payment Issue - Invoice #[Invoice Number]
Dear [Vendor Representative],
We recently attempted to process payment for Invoice #[Invoice Number] in the amount of $[Amount], but the transaction was rejected by the receiving bank.
For security, updated banking instructions must not be sent in plain email. Please reply to this message and we will send a separate Email with a secure upload link, or return the completed PDF bank verification form attached to your Jira vendor profile update ticket (OPS-VND-[VendorID]) as instructed in our follow-up. Do not include full account numbers in email body text.
Best regards,
Finance Operations | Vanguard Shield Mutual
Subject: Vanguard Shield Mutual - Action Required: W-9 Needed for Vendor Account #[Vendor ID]
Dear [Vendor Representative],
As part of our annual tax compliance review, we noted that Vanguard Shield Mutual does not have a current valid Form W-9 on file.
Because year-to-date disbursements have exceeded the IRS reporting threshold, a temporary administrative hold has been placed on future payments.
Please reply to this email with a completed, signed PDF copy of your current W-9. Once received and validated, we will remove the payment hold.
Best regards,
Compliance Operations | Vanguard Shield Mutual
Subject: Vanguard Shield Mutual - Payment Status Update - Invoice #[Invoice Number]
Dear [Vendor Representative],
Thank you for contacting us regarding Invoice #[Invoice Number] in the amount of $[Amount]. At this time, our records show the invoice payment is [Pending/Processing/Approved-Unpaid/Under Review] and has not completed clearing.
We are reviewing the payment status and will follow up once it has cleared or if additional information is required. If you have questions or believe this payment is past due, please reply to this email and we will prioritize the review.
Best regards,
Finance Operations | Vanguard Shield Mutual | support@vanguardshield.com | 1-800-555-0199
B-1 Suspense; B-2 T&E DM; B-3 Wire compliance (Jira); B-4 Wire pointer (Slack); B-5 AR billing contact; B-6 Expense variance; B-7 Liquidity transfer; B-8 Manager lookup
Use as: Jira ticket description (FIN-Exceptions).
[Suspense Escalation] - Transaction ID: [ID Number]
Status: Requires Controller Review
Amount: $[Amount]
Details: This item has been sitting in Intercompany Suspense. No PDF receipt was found on the linked Jira issue, and/or prior Slack approval is missing.
GL Conflict (if applicable): Invoice GL: [Code A] | Excel GL: [Code B] | Resolution requested.
Action Required: Controller (per queue pinned issue), please review and advise on proper GL coding or request documentation from the originating department.
[T&E Review Flag] - Employee ID: [Employee ID]
Expense Date: [Date] | Amount: $[Amount]
Merchant: [Merchant]
Details: Expense submitted without a matching Calendar event, or Shopify promo purchase not
found. Action Taken: Line item rejected in Jira OPS-HR-TE workflow. Please review with your direct report.
Use as: Full description body when dual Slack approval is missing per §3.3.
[Wire Control Exception] Wire ID: [Wire ID]
OPS-TRE-WIRE issue: OPS-TRE-WIRE-[WireID]
Population source: International wires population workbook from OPS-TRE-WIRES-[Quarter] (attach excerpt row or link)
Slack evidence: Channel #treasury-wires | Queries attempted: (1) has:link [Wire ID] (2) in:#treasury-wires [Wire ID] (3) in:#treasury-wires "[Wire ID]" | Result: [which query worked OR Slack search exhausted]
Approvers found: [Name / Title / exact Approved text] for Approver 1; [same for Approver 2] OR state Missing dual approval
Exception code applied on wire issue: TRE-900 High-Risk Exception
Action requested: Chief Compliance Officer (per Compliance-Alerts board pinned issue) to determine corrective action and whether wire may proceed.
Use as: Mandatory immediately after filing the Compliance-Alerts issue in §3.3 (same business day). Do not include dollar amounts, beneficiary bank data, or full wire instructions.
[Compliance] International wire control exception filed — Jira: [COMPLIANCE-ALERTS-KEY] | Wire ID: [Wire ID] | OPS-TRE-WIRE-[WireID] | Analyst: [Your name]
Use as: Slack message when OPS-AR-CLIENT has no billing email and demand letter is on hold.
[AR Ops] Billing contact needed | Client ID: [Client ID] | Jira: OPS-AR-CLIENT-[ClientID] | Aging bucket: [90+] days | Analyst: [Your name] | Action: Add Billing Contact Email to client issue description—demand letter not sent.
Use as: Paste into Jira FIN-Exceptions description under the title from §2.2.
[Expense Variance Escalation]
Department: [Department] | Quarter: Q[N] | Line item: [Line item name]
Budget: $[Amount] | Actual: $[Amount] | Variance %: [x]%
Mailbox searched: [e.g. finance.ops@vanguardshield.com]
Search terms (exact): [terms]
Date range: [Start]–[End]
Attachments: variance memo for the department/quarter (Word, §1.4); the budget-vs-actual export from the BVA issue
Request: Controller (per queue pinned issue) to advise disposition (obtain justification / reclass / other).
Use as: Paste into Jira TRE-Investments description for §3.1 Route for approval.
[Liquidity Transfer Request]
OPS-TRE-LIQUIDITY issue: OPS-TRE-LIQUIDITY-[YYYY-MM-DD]
Balance read: $[balance] at [time ET] | Attachment: [liquid position file name as shown on OPS-TRE LIQUIDITY]
TransferAmount (per rounding rules): $[amount]
Fund / instruction: Overnight Money Market (cite line from liquidity package)
Link: Jira snapshot comment URL or comment ID on OPS-TRE-LIQUIDITY
Use as: Jira HR-Ops description body and/or Email body to hrops@vanguardshield.com (identical text).
[T&E Manager Lookup]
Employee: [Name] | ID: [ID]
OPS-HR-TE / expense report issue: [KEY]
Directory / People search result: [e.g. Reporting Manager field blank; people@vanguardshield.com returned no match]
Need: Correct manager Jira username or Slack handle for Template B-2 notification.
Codes used in Jira labels, comments, or workflow:
FIN-201 Vendor AP Hold — missing W-9 PDF or failed banking verification. • TRE-900
High-Risk Exception — wire lacks dual Slack approval evidence. • UND-304 Audit
Variance — audited premium materially differs from estimated basis.
CLM-440 Subro Potential — closed paid claim triage; police report indicates third-party fault language.
CLM-999 SIU Hold — photo match (Identical or Same-angle per §7.3), inspector inconsistency notes, or date-metadata inconsistency undermining loss timing.
CLM-910 Identity Verification Hold — death certificate mismatch vs insured record. •
CLM-920 Complex Beneficiary Hold — legal/beneficiary conflict documentation present.
Save as: Word memo per §1.4 (include department and quarter).
MEMORANDUM
TO: Financial Controller (per FIN-Exceptions queue pinned issue)
FROM: Operations Analyst DATE: [Current Date] SUBJECT: Expense Variance Analysis - [Department Name] - Q[Number]
Finding Summary:
During routine variance analysis, the line item for [Expense Category] was flagged for exceeding the 10% variance threshold.
Budgeted Amount: $[Amount]
Actual Spend: $[Amount]
Percentage Variance: [X]%
Investigation Results:
Supported Outcome (if justification is found): On [Date], [Department Head Name — from Jira “Department Head” field per §1.3] approved/authorized the spend for [Reason]. Evidence: [Email subject] from [Sender] located in mailbox [Inbox name] using search term(s) “[Terms]” for date range [Start Date]– [End Date].
Unsupported Outcome (if no justification is found): A search of mailbox [Inbox name] for date range [Start Date]–[End Date] using term(s) “[Terms]” did not locate a business-justification email or approval for this over-budget line item. No reason has been inferred. Escalation: [Jira Ticket Key] created / (if not yet created) “Pending Controller guidance.”
Investigation Details: [Optional free text]
Conclusion Options: (a) Supported—No further action required; retain evidence and file memo in Jira. (b) Unsupported—Escalated for Controller guidance; do not close until disposition is received.
Save as: Word SIU referral per §1.4 (include claim number).
MEMORANDUM
TO: Special Investigations Unit (SIU)
FROM: Claims Analyst
DATE: [Current Date]
SUBJECT: Claim Anomaly / Fraud Indicator Referral - Claim #[Claim Number]
Claim Details:
Policyholder: [Name]
Date of Loss: [Date]
Reported Cause: [Cause]
Reason for Referral:
During standard claim review in Jira (claim issue CLM-[number]), the following anomalies were
identified: • Photographic Inconsistency: [Describe which photo matches which prior claim number]
report]
Action Taken:
Claim status updated to CLM-999 SIU Hold.
Payment activity is frozen pending SIU investigation.
Use as: Demand letter PDF attachment for clients > 90 days overdue when no payment plan exists. Complete all bracketed fields exactly as shown. Export to PDF per §1.4 (include client ID and date).
VANGUARD SHIELD MUTUAL
ACCOUNTS RECEIVABLE DEMAND LETTER
Date: [Current Date]
Client ID: [Client ID] Amount Due: $[Amount]
Invoice(s): [Invoice Number(s) if available]
Days Past Due: [#]
To whom it may concern,
Our records indicate that the amount listed above remains outstanding and is more than 90 days past due. Please remit payment or contact our Accounts Receivable team to confirm the status of this balance.
Requested action: Please respond within 10 business days of the date of this letter with one of the following: (a) confirmation that payment has been submitted (including payment date and reference), or (b) a proposed payment plan and timeline.
If we do not receive a response within the timeframe above, the account may be placed on Collections Hold on the AR Jira record (OPS-AR-CLIENT-[Client ID]) while the balance is addressed.
Sincerely,
Accounts Receivable
Vanguard Shield Mutual
support@vanguardshield.com | 1-800-555-0199