The short answer: This guide is for the Support Escalations Team. If you're not part of this team, refer to the Guaranteed Rate Integration Support Guide instead. DocuTech (DT) is the integration layer between a customer's Loan Origination System (LOS) and Proof. This guide covers the issues, questions, and edge cases support runs into most often: filing a DT case, common customer FAQs, LOS pushback configuration, known system constraints, and current status on active customer cases.
How to File a DocuTech Support Case
Customer-filed cases
The customer needs to log into their own DocuTech account and file the case themselves. There's no way for us to transfer a case or file one on their behalf.
Proof employee escalations
Email pr@docutech.atlassian.net and CC tcsm@proof.com on the escalation.
Full workflow details live in DocuTech's own guides — use this article for the issues support hits most:
Common Issues (FAQ)
Signer can't pass Knowledge-Based Authentication (KBA) +
DT customers often assume Proof can be used for any transaction that can't be wet-signed, including international signers who don't have an SSN. Under DT's current settings, a signer with no SSN cannot pass KBA. Customers can see the Identity tab in the UI, but not the underlying ID report.
Give the customer the same KBA guidance we give everyone else:
- Confirm the signer's name matches exactly across documents.
- If the signer has no credit background or history, they won't be able to pass KBA.
- The signer needs a valid U.S. address on file.
- The signer needs an ITIN or SSN.
- Sometimes a signer simply can't pass KBA — that's expected behavior, not a bug.
- Check whether a spouse or partner is attempting to sign in place of the correct signer — often visible as the same email address being reused. Escalate to the TCSM to discuss enabling "lock recipient name," which is now on by default for all new deployments.
"I can't add someone to the account" +
Follow standard guidance — merging accounts is acceptable. SSO will block moving or adding anyone whose email uses a First American domain (DocuTech employees only).
"I need something signed in a specific state or by a specific title agent" +
Not supported. This isn't how the DocuTech/Proof integration or the customer's LOS workflow is designed to work.
Name, address, or other loan data is incorrect +
The loan needs to be redrawn at the source. Don't update loan data directly through the Proof UI — it can break the LOS write-back integration (see Known System Constraints below).
LOS Pushback Configuration & Troubleshooting
The LOS Pushback event determines how completed or updated documents flow from Proof back into the customer's image repository via their LOS. Configuration is customer- and LOS-specific — always confirm proposed changes with the customer's LOS before submitting a DTX ticket.
Issue #1 — Duplicate Unsigned Documents (RON transactions)
First confirm which LOS Pushback event the customer's LOS uses to retrieve unsigned closing packages — without that, it's difficult to confirm whether a config change will fully resolve the issue. For RON-specific cases, the following change typically eliminates duplicate unsigned documents in the Added and Modified pushback events:
Setting this to "Yes" excludes unsigned, ink-signed document copies from the Added and Modified LOS Pushback events (eSign/eClose), which eliminates the duplicates.
Issue #2 — Executed RON Documents Missing from Pushback
Executed RON documents are sometimes sent only through the Added and Modified pushback events — not through eCloseSignAndSubmitAllComplete, the event most LOS integrations actually use to retrieve complete closing packages. This is caused by the following setting:
The individual-PDF option isn't compatible with the RON workflow, which is why executed documents are excluded from eCloseSignAndSubmitAllComplete. This setting is LOS-dependent — confirm with the customer's LOS that it can support the change before submitting a DTX ticket.
Known System Constraints & Limitations
Customer Case Studies
NFTYDoor and loanDepot both use the DocuTech–Proof integration, but their root causes and current status are quite different.
NFTYDoor — Notary Tagging & Acknowledgment Issues +
Primary issue: notary acknowledgment tagging
The DocuTech integration sends a free-form "fill in here" text box for notaries to manually type signer names, instead of a pre-tagged/printed name field. Notaries frequently delete or mismanage these tags, causing inconsistent or missing information. Over $4 million in loans in NFTYDoor's pipeline were rejected at recording as a result.
Potential solutions considered: acknowledgment blocks with pre-printed names, enforcing required fields (which conflicts with DocuTech's Patriot Act document requirements), or moving to printed signer-name tags.
Secondary issue: missing tags on lender-uploaded documents
Some documents (e.g. Application.pdf) were uploaded directly by the lender rather than generated by DocuTech, and lacked the coordinates needed for automated tagging. Note: a document that wasn't tagged by DocuTech, but was included by the customer as part of the package, can still pass through with the rest of the package.
Status: Resolved. NFTYDoor confirmed on June 22, 2026 that they identified the internal tagging gap and deployed a fix. Documents are signing correctly — no further action needed.
loanDepot — Document Encoding & Rendering Errors +
Unlike NFTYDoor, loanDepot's issues are technical/document-level rather than notary tagging errors.
Symptom: "Glitch" errors on ancillary documents and eNotes — the borrower appears to engage with the document, but the system fails to apply or recognize the signature.
Root cause: an encoding/format mismatch and rasterization issue with specific documents coming through the DocuTech integration — these documents are structurally broken before they reach Proof.
Resolution: handled case-by-case (refunds, or requiring a wet signature to complete). Escalate document-format issues directly to DocuTech, since the error originates at document origination, before reaching Proof.
Support & Process Notes
Known challenges
- Siloed support channels: DocuTech uses its own ticket portal (DTX) with contract-specific SLAs, so Proof teams often have to direct customers to open their own DocuTech ticket rather than handing it off directly.
- Visibility & alerting: better automated alerting on integration health (API timeouts, authentication failures, certificate expirations) is needed so breaks don't go unnoticed for days.
- UI interference: lenders should limit interaction with the Proof UI. Manually adding trailing documents or editing transaction data (e.g. title/underwriter info) directly in the UI can break the automated write-back/pushback integration.
Best practice
Treat the customer's LOS as the system of truth. If a change is needed after a transaction has been sent, the recommended approach is to submit a new, corrected transaction rather than editing the active one in the Proof UI. Cross-team work is ongoing to bridge Proof/DocuTech support processes and create more streamlined escalation paths for shared customers.
Quick Reference Notes
Solutions Guide for Sumo & ADX queries: DocuTech Solutions Overview
Summary Checklist
- Confirm whether this is a customer-filed DT case or one that needs Proof-side escalation to pr@docutech.atlassian.net (CC tcsm@proof.com).
- For a failed pushback, re-trigger it via Keystone's "Pushback documents to Docutech" task before escalating.
- Check the known constraints table before treating unexpected behavior as a bug.
- Confirm any LOS Pushback config change with the customer's LOS before submitting a DTX ticket.
Updated