Prove one workflow before expanding.

One agreed document workflow, built across a defined set of your systems and document types, delivered over 30 implementation days for a fee fixed before the work starts. It is a bounded engagement with a written definition of done, not an open-ended automation program.

That one real workflow in your firm can run end to end on your systems, with actions logged, exceptions visible, and a human review step before anything is filed. It also establishes the baseline a longer engagement would be measured against.

It does not prove a return-on-investment figure. 30 implementation days is not a large enough sample, and the honest return is capacity rather than cost.

Most pilots begin with individual return document intake, or with month-end close preparation for a client accounting services team. Whichever it is, the workflow, the systems, and the supported document types are named in the statement of work before implementation starts.

• One workflow, one review queue, one exception path.
• A defined set of systems and intake routes.
• A defined list of supported document types, with known exclusions written down.
• One filing or handoff destination.

The implementation clock begins after required access, approvals, system documentation, and a workflow owner are available. Procurement and security review sit before that point, not inside the thirty days.

• Approved access to the systems the workflow will run in.
• Provider accounts, or authorization to use the firm’s existing accounts.
• Documentation of the systems in scope, or time with someone who knows them.
• One workflow owner — a person, not a committee.
• A decision on which data the pilot may use, and under what restrictions.

The sequence inside the window adapts to what the systems in scope actually support. Mapping and acceptance criteria come first; handoff and training come last.

Before implementation, the firm and Gulf & Ponte agree on observable operational behavior such as supported intake routes, review requirements, exception visibility, action logging, and approved handoff.

Operational behavior can be tested during the pilot. Capacity, cycle-time, and staff-time outcomes may require a longer production sample.

We do not publish a numerical extraction-accuracy threshold. Accuracy depends on the document mix, the source quality, and the fields in scope, and a number quoted before seeing your documents would be marketing rather than a commitment.

• Current-state workflow map
• Provider and data-flow inventory
• Configured workflow with a review and exception path
• Acceptance checklist
• Runbook
• Access and credential inventory, without exposing secrets
• Workflow-owner training
• Documented known limitations
• Transition or shutdown instructions

Hosting, repository access, code ownership, support, and transition terms are defined in the statement of work.

• Your accounting. We do not prepare, review, or sign anything.
• A §7216 legal opinion, or any legal conclusion. Your counsel makes that determination.
• Replacing your tax software, portal, or practice-management system.
• Migrating historical documents. The pilot runs forward from go-live.
• Any final filing without a human review step during the pilot.

Three outcomes are all fine. You operate what was built using the runbook and stop there. You continue on a monthly retainer covering operation, changes as your process changes, and the next workflow. Or the pilot shows this is not worth extending, in which case you have a documented workflow map, an access inventory, and shutdown instructions rather than a dependency.